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ECARS 2.0 Architecture 

1. introduction 

The ECARS 2.0 application is an operational system designed to support Enterprise Rent-a-Car's 
Rental line of business. The application will ultimately replace the existing AS/400 based 
ECARS 1.0 application. However, due to external dependencies, integration to the existing 
system is an integral part of the new ECARS application. 


The following document is intended to describe the overall architecture of the ECARS 2.0 system 
at a conceptual and logical level. For physical implementation specifics reference the documents 
specified in Appendix A. 

2. Conceptual Architecture 

At it's highest level, the ECARS 2.0 system is composed of seven main components; the 
p Application Client, Web Application; AS/400 Interface Programs, AS/400, ECARS 1 .0 to 

ECARS 2.0 Synchronization, ECARS 2.0 Database, and the Rates Pricing Engine. 


Ill 


s s 
7IS3T 


%l The Application Client represents any client to the application. This includes the web based user 

interface, or external application interfaces. The Web Application encompasses the ECARS 2.0 
business logic as well as the logic to render the pages for the user interface. The AS/400 
interface programs are used to leverage functionality from the existing AS/400s or to synchronize 
Li data with them. The AS/400s process several applications including the current ECARS 1 .0. The 

f| j ECARS 1 .0 to ECARS 2.0 Synchronization is used to synchronize data from the AS/400 to the 

ECARS 2.0 application. The ECARS 2.0 Database serves as the main data storage for the 
ECARS 2.0 application. Finally, the Rates Pricing Engine is the component used to generate all 
Rate related information for ECARS 2.0 and future external applications. Each of these 
components will be discussed in more detail in the subsequent sections. 
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Programs 
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Engine 
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Data 


Transformation 

1 
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Figure 1 - ECARS 2.0 Conceptual Architecture 


3. Logical Architecture 

3.1 Application Client 

3.1.1 Thin Client 

The ECARS 2.0 application has been designed to utilize a thin client for the user interface. The 
generated HTML pages are generally lightweight with no applets and minimal JavaScript. These 
pages are displayed in an Internet Explorer browser running on a terminal server at the branch. 
This allows for minimized deployment complexities while leveraging currently available 
technologies. 


While most features utilize traditional Web technologies, the ECARS system has a requirement to 
know the physical location of a request. This requirement is not inherently supported using Web 
technologies. Therefore, the ECARS application leverages a script running on the Terminal 
Server to access the Active Directory and create a cookie with the user's physical location. This 
cookie is retrieved by the ECARS application to determine the physical location of the request. 
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3.1.2 External Clients 

The Enterprise Rent-a-Car environment consists of several applications whose combined 
responsibility is to support the day-to-day operations of the company. The ECARS 2.0 
application has been designed to leverage some of these existing assets as well as provide 
functionality to others. These external clients support differing levels of communication and 
integration. Therefore, to support the wide range of application interfaces, the ECARS 2.0 
application has been designed to support four main methods of integration: JMS Messaging, 
RMI, Web Services, and the WebLogic/Tuxedo Connector. 

Currently, JMS messaging is being considered for asynchronous calls from external clients. The 
JMS message would be consumed by a Message Driven Bean within the ECRS 2.0 Web 
Application and processed accordingly. 

Alternatively, for synchronous calls, the ECARS 2.0 Application can support RMI and Web 
Service calls. However, the Web Service approach is currently favored over direct RMI calls. 
This is due to the looser coupling between applications using the Web Service approach. 

Finally, the WebLogic/Tuxedo Connector will be utilized to provide an interface for Tuxedo 
based applications to leverage ECARS 2.0 functionality. This allows WebLogic to appear as a 
Tuxedo domain and thus allows a Java process to appear as a Tuxedo service. Therefore, 
external Tuxedo services will be able to call a Java process using the same method as it would to 
call a different Tuxedo service. 


3-2 ECARS 2.0 Web Application 

The ECARS 2.0 Web Application has been designed to leverage Java, J2EE and browser based 
technologies. Its implementation relies heavily on industry standards, design patterns, and best 
practices. When looking at the application functionality, it can be segregated into four Logical 
tiers that are deployed onto several physical tiers. 
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Data 


Thin Client 


I 


Terminal Server 


Web Server 
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Web Logic Cluster 



Logical Tiers 


Physical Tiers 


Figure 2 - ECARS 2.0 Web Application Tiers 


The Client tier represents a thin client user interface. This interface contains very little business 
logic and consists solely of HTML pages with JavaScript. These pages are rendered within an 
Internet Explorer browser and are generated from Java Server Pages, 


The Control tier is responsible for generating the HTML/JavaScipt pages, managing navigation, 
transforming data, and performing field level validations (e.g. did the user enter a numeric value 
in a numeric field). 


The Business tier consists of the logic for the application business rules, validations, and data 
interactions. These are implemented using EJBs and Java Classes. 


The Data tier represents the data storage for the application 
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Currently, these four Logical tiers are deployed onto several Physical tiers. The Client resides 
within a Web Browser running on the Terminal Server and a Thin Client. The Control and 
Business Logical Tiers are currently deployed on a cluster of WebLogic servers. The Data Tier 
resides on an Oracle 8i database. Due to the dynamic nature of the application, no static content 
resides on the Web Server cluster. However, while the Web Server provides no application 
functionality, it is required to support load balancing and failover for the WebLogic cluster. 
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3. 2. 1 Web Application Components 
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Figure 3 - ECARS 2.0 Web Application Components 
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3.2.1.1 Action 

The Action encapsulates any processing logic that was requested or required prior to displaying a 
page or when leaving a page. For example, if a request is made to save a reservation, an Action 
will delegate to other objects and ensure the data is aggregated correctly. If so, the Action will 
initiate a call to a Use Case Manager to ultimately save the data. 


3.2.1.2 Action Factory 

The Action Factory is responsible for creating instances of Actions and pooling them for reuse. 


3.2.1.3 Adapter 

The Adapter is a data mapping mechanism to transfer data between the Form and the Domain 
Object. 


3.2.1.4 Browser 

HTML and JavaScript based user interface. 


3.2.1.5 Custom Tag # 

Custom Tags are Java objects used to encapsulate presentation logic required to present dynamic 
content from the JSP. Example tags include a tag to create an HTML table of drivers, a color 
indicator based on reservation status, etc. 


3.2.1.6 DB 

The DB contains all of the SQL for transactions with the database. 

3.2.1.7 DB Factory 

The DB Factory transfonns data between Domain Objects and Model Objects. One Domain DB 
Factory may call another one to support more complex transactions. For example, to save a 
reservation, a Reservation Domain (with associated Driver Domain, Bill To Domain, etc.) will be 
passed to a Reservation DB Factory. The Reservation DB Factory will then delegate to other 
factories as required to process other Domains such as Driver and Bill To. The DB Factory may 
also serve as a data cache if required. 

3.2.1.8 Domain Object 

The Domain Object is a data holder for information passed through the system. Hiese are 
typically business objects such as a Reservation or a Driver. 

3.2.1.9 Form 

The Form is a data holder for information required during a user session. Typically, these objects 
are more course-grained than a Domain Object and represent aggregated data required for the 
display of a page. 
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3.2.1.10 JSP 

The JSP is responsible for creating an HTML page based on dynamic data. It does so by 
executing on the application server with a combination of HTML, JavaScript, and calls to Custom 
Tags. 

3.2.1.11 Main Sen/let 

The Main Servlet is responsible for receiving all requests made from the browser. The Main 
Servlet takes data from the request and places it into a Form for processing. While doing so, the 
Main Servlet will utilize helper classes to perform field level validations such as a valid date 
entered in a date field. The actual application processing is delegated from the Main Servlet to an 
Action. 


3.2.1.12 Model 

The Model is an object representation of a result set from a data source. These objects are used to 
provide an additional layer of isolation between the data structure and the Domain Objects within 
the application. 

t 

3.2.1.13 Session 

The Session (not pictured above) is used to temporarily store data specific to a user's interaction 
with the system. Typically, Forms or Domain Objects will be stored with the Session to enable 
application processing. These objects are typically removed when a user leaves a page and the 
data is no longer required. 


3.2.1 .14 Use Case Manager 

Encapsulates a call from the Action to the Application Layer. 


3.2.1.15 Use Case Manager Bean 

The Use Case Manager Bean is responsible for implementing business logic in the Application 
Layer. The Use Case Manager Bean is responsible for managing the complete transaction with 
the database. 


3.2.1.16 Validator 

Validator objects are responsible for validating a Domain Object. Validators are specific 
Domain Object and can be "chained" together to enable stricter validation rules. 


3.2.1.17 Web View 

The Web View is an object representation of an entry in the XML file. 
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3.2.1.18 Web Views 

Web Views is the object responsible for parsing the XML configuration file and creating the 
appropriate Web View objects. This object also maintains a pool of Web View objects; therefore 
the XML file does not need to be re-parsed for each request. 


3.2.1.19 XML Configuration File 

This file contains properties for all page requests. Information specified in the file for each page 
includes: possible navigation destinations, page field elements, the Enter Action, and the Exit 
Action. 
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3. 2. 2 User Request Processing 

The following sections describe the lifecycle of a typical user request on the ECARS 2.0 Web 
Application. 

3.2.2.1 Control Processing 

As illustrated in Figure 4 below, the MainServlet serves as the main entry point into the ECARS 
2.0 Web Application. When the MainServlet receives a user request, it first retrieves an instance 
of the WebViews object. It then retrieves the WebView object corresponding to the user request. 
If this is the first request into the application, the WebViews object will parse the application's 
XML configuration file to generate a pool of WebView objects. 

Once the MainServlet has retrieved the WebView object, it will get a list of Form Fields from the 
WebView. These Form Fields represent fields on the web page and map directly to attributes in 
the web page's corresponding Form Object. The MainServlet uses the list of Form Fields to get 
data out of the HTTPServletRequest and set it in the appropriate Form. While doing so, the 
MainServlet may use Form Field Validators to validate that the data is the correct type (e.g. 
numeric data for a numeric field). 

After the data is processed from the request and placed into a Form object;, the MainServlet 
retrieves the Action that corresponds to the page that the user is exiting. The MainServlet then 
delegates to the Action for any application processing that may be required when the user leaves 
the page. For example, if a user chooses to save some data, this logic would mostly likely be 
encapsulated into the exit processing for the save page (details of the page exit processing is 
described in Section 3.2.2.2). 

If the page exit processing was not successful, the MainServlet will process the error using the 
application's exception handling components. Otherwise, the MainServlet will retrieve the 
Action corresponding to the page that the user would like to navigate to. Similar to the page exit 
processing, The MainServlet will delegate to the Action for all processing that is required prior to 
displaying the page. For example, the retrieval of data for display to a user could be encapsulated 
into the page enter processing (details of the page exit processing is described in Section 3.2.2.3). 
Then, to display the page, the MainServlet forwards or redirects the request to the corresponding 
JSP. 
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3.2.2.2 Page Exit Processing 

As mentioned above, the page exit processing is responsible for the application logic when a user 
exits a page in the application. Usually this entails operating on some data that the user has 
entered or modified on the screen. In earlier functionality, the MainServlet has processed this 
user data and put it into a Form object. Since this object represents screen data and not business 
objects, the data can be difficult to process and validate. Therefore, the Action utilizes an 
Adapter to take the data from a Form and places it in a Domain object. The Action can then 
begin to process the data or pass it to the UseCaseManager for detailed business processing or for 
data storage/retrieval. (This process will be described in more detail in section 3.2.2.4) 


MainServlet 


Action 






performOnExit 


getlnstance 



toDomainObiect(Fjo rm) 

getData 


setData 


Business Processing 




Figure 5 - ECARS 2.0 Web Application Page Exit Processing 


3.2.2.3 Page Enter Processing 

The page enter processing is typically used to initialize content for pages and to retrieve data for 
display. To achieve this, the Action delegates to the UseCaseManager to retrieve required data in 
the form of one or more Domain Objects. The Action then uses an Adapter to transform the data 
into a Form for display by the JSP. 
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Era? 

Business Processing 
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toFormBean(DomjainObject) 
getData 
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Figure 6 - ECARS 2.0 Web Application Page Enter Processing 


3.2.2.4 Business Processing 

The business processing is responsible for performing business validations, executing defined 
business processes, and managing transactions with the data sources. The process begins when 
the UseCaseManagerBean receives a request from a UseCaseManager or an external system. 
Any data passed UseCaseManagerBean is validated using a Validator object. 


If valid and the business process requires saving data, the UseCaseManagerBean delegates to a 
DB Factory and passes the Domain Object. The DB Factory processes the Domain Object and 
transforms the data into a Model or set of Model classes. Additionally, if required, the DB 
Factory may delegate some processing to an additional DB Factory. Once data has been placed 
in a Model, it is passed to a DB object to execute the SQL or corresponding data access method. 


Similarly, if the business processing requires retrieval of data the DB Factory delegates to the DB 
for data access. The DB object places the result set into one or more Model objects. The DB 
Factory then maps the Model data into one or more Domain Objects and passed back to the 
requestor. 


Confidential 


©Enterprise Rent-A-Car, 2000 


Page 17 of 26 


s 


c 3 


[Jib 

f* i© 
O 


> 


Q 


'1 < 


5.-,: 


O 
■4— » 

I 


g 

+^ 
O 

-C 

o 

< 

q 

CO 

< 

3 


■> 
O 

O 

M 

< 
© 

CO 

< 



<4-4 
O 

00 
Oh 






s 




s 


« 


S 


0) 








0) 


GO 


5 



B 

£ 

s- 

a 

CO 

TEL 


I 

£=3 

i 

s 

•»■« 


Rental Redesign 


ECARS 2.0 Architecture 

ECARS 2.0 Architecture Overview 


Version: 1.0 


Date: 12/20/01 10:25 AM 


3.3 AS/400 

The existing ECARS application runs on seventeen AS/400s. The functionality is distributed by 
user base such that one AS/400 serves the Midwest, one serves the North East, etc. 

3.4 AS/400 Interface Programs 

3.4. 1 ECARS 1. 0 Rates Interface 

The ECARS 1 .0 Rates Interface is a temporary interface required to support the initial 
Reservation pilot functionality. Eventually the Rates Pricing Engine will replace this interface. 
The current interface consists of UNIX Tuxedo services, AS/400 Tuxedo services, and AS/400 
Wrapper programs. To make this architecture fault tolerant and highly available, the UNIX 
Tuxedo service serves as a Domain Gateway to the AS/400 Tuxedo services. This configuration 
allows the architecture to take advantage of Tuxedo's Domain to Domain communication model 
rather than having to build the failover into the ECARS 2.0 Web Application. 

A typical transaction for the ECARS 1 .0 Rates Interface would begin with the ECARS 2.0 Web 
Application making a request to a UNIX Tuxedo service through Jolt 1 . 


ECARS 2.0 
Web Application 


UNIX Tuxedo 
Services 


AS/400 Tuxedo 
Services 


Rates Wrapper 
Program 


Figure 8 - ECARS 1.0 Rates Interface 


1 The current architecture is designed to use Jolt for ail Java to Tuxedo requests. While this architecture works, it introduces 
complexity due to the required addition of UNIX Tuxedo. To reduce these issues, the WebLogic/Tuxedo Connector (WTC) is 
currently being evaluated as a potential replacement for Jolt Using the WTC, WebLogic will act as a Tuxedo Domain and will 
therefore eliminate the need for a separate UNIX Tuxedo domain. 
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3.4.2 ECARS 2.0 to ECARS 1.0 Synchronization 

When data is saved in the ECARS 2.0 application, it often must be synchronized with data on the 
AS/400. Based on business requirements, this process is implemented asynchronously using a 
polling technique 2 . The process starts when data is saved in the ECARS 2.0 Web Application. 
At this point an entry is put into a queue for processing. A Java thread running within the Web 
Application periodically reads the queue and begins to process the entry. Because the data 
formats and structures are different on the two systems, the Java process begins by retrieving 
additional data and performing data transformations. Once complete, the Java thread sends the 
data to a UNIX Tuxedo service through Jolt. Similar to the ECARS 1 .0 Rates Interface, the 
UNIX Tuxedo serves as a Domain Gateway to on one of seventeen AS/400 Tuxedo Domains. 
Then, the data is passed by the AS/400 Tuxedo service to a wrapper program on the AS/400. The 
AS/400 wrapper program performs AS/400 specific validations and the saves the data. A return 
code is then returned to the Java process to indicate the success or failure of the transaction. 


Create/Update Data 


ECARS 2.0 
Data I/O 


ECARS 2.0 Web ApplicatiSfc 


ECARS Synch 
Process 


UNIX Tuxedo 
Services 


AS/4&4 


AS/400 Tuxedo 
Services 


* 


Data Wrapper 
Program 



f if 


ECARS 2.0 


Figure 9 - ECARS 2.0 to ECARS 1.0 Synchronization 


3.4.3 ECARS 1 .0/2.0 Cross Platform Record Locking 

The ECARS 1 .0 application maintains a lock table to indicate record locks within the AS/400 
system. External applications and other ECARS 1.0 processes verify the lock status in the table 
prior to locking the record. If a lock does not exist, the system enters a record in the table and 
then obtains a physical lock on the record in the lock file. 


2 


Future implementations may eliminate the polling technique in favor of a JMS based asynchronous solution. This will increase 
performance by reducing the data retrieval requirements and by reducing the network traffic associated with polling. The JMS 
based solution, however, would continue to utilize the Tuxedo based architecture. . „ 
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In contrast, the ECARS 2.0 system uses time based logical locks on all transaction based data. 
This strategy has been implemented by adding a timestamp and user ID to the database record to 
indicate when and by whom a lock has been acquired. Currently, the system allows a user to hold 
a lock for up to thirty minutes, however this is configurable to adjust the default lock time. 


Since the ECARS 1 .0 and ECARS 2.0 systems will be active at the same time, there is a 
requirement to support cross platform record locking. Furthermore, due to the diverse AS/400 
programs that use the lock file, it is desired to minimize the impact on the existing programs. 
Therefore, to accomplish this requirement, the ECARS 1 .0 record lock file will serve as the 
master record lock for cross platform locks. 


For a given transaction within the ECARS 2.0 system, the application would first inspect the ^ 
logical lock within the ECARS 2.0 database. If the application were able to acquire the lock, it 
would then attempt to acquire the AS/400 lock via the ECARS 2.0/1 .0 record lock process. The 
ECARS 2.0/1 .0 record lock process would inspect the lock file to see if the transaction was 
locked. If not, the process would enter a record in the lock table and then acquire a physical lock. 
The process acquiring the lock would be configured to expire based on the same logical lock time 
established for the ECARS 2.0 system. 


ECARS 2.0 


ECARS 2.0 Database 


ECARS 1.0 




ECARS 2.0/ 
1.0 Record 
Lock Process 


Record 
Lock File 




Figure 10 - ECARS 1.0/2.0 Cross Platform Record Locking 
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3.5 ECARS 1 .0 to ECARS 2.0 Synchronization 

The ECARS 1 .0 reservation data is processed thru Wrapper program(s) on the AS/400. This 
information is then passed to a transformation file, which contains the cross-reference data for the 
ECARS 2.0 and ECARS 1 .0 reservation number mapping etc. There are individual triggers that 
map one to one with e*Gate scripts. These E*Gate scripts use the cross-reference file(s) for 
writing to the e*Gate input transaction file EX001P. The rules specific transformation scripts 
will then write the data to the ECARS2.0 Oracle Data base. 
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3.5. 1 AS/400 Stored Procedures 

The AS/400 stored procedures are used to poll unprocessed data from an AS/400 transaction file. 

3.5.2 Polling Scripts 

The polling scripts are used to facilitate the execution of the AS/400 stored procedures. The data 
being pulled from the North American machines varies only in the size of the last fixed length 
field from the European machines. 

3.5.3 Routing Script 

The Routing Script is used to direct incoming files from the IQ to the correct cascade. The 
Routing Script first loops through each record and matches the current record to the previous 
records. 

3. 5. 4 Cascades and Table Level Integrations 

The lower two levels of the three-tier dart script architecture consists of the cascade scripts and 
the table level integration scripts. 

3.5.5 Cascade 

The cascade scripts basically execute each of the BULK Table Level Integrations scripts in the 
correct sequence. Depending on the data sorted from the Routing Script tjie cascade will receive 
the records contained in a single fixed length string. All data received will be from the same file, 
for the same operation, and be for North America or European. The Routing Script executes the 
cascades file. 

3. 5. 6 Table Level Integrations 

At this level, required and relevant data are mapped. There are 2 basic types of table level 
integration scripts: Bulk and Line mode. Bulk scripts are the primary method for data 
integration. Bulk scripts using the DBMS_SQL package attempts to insert or updates up to 750 
records at one time. Bulk script will not return an error, because in the event of an error the Bulk 
script will execute the equivalent Line script. The Line scripts are the secondary method for data . 
integration. Line scripts attempt to update or insert a single record at a time. In the event of an 
error, the script will send an event to the e*Gate monitor for each record that contained an error. 

3. 5. 7 Monk Dart Scripts 

There are fours types of monk scripts used in this project architecture Routing, Cascade, Table 
Level Integrations, and Poll scripts. Most DART scripts are categorized as either Bulk or Line 
Table Level Integrations. Each type of script follows a common flow of logic and the only 
difference from script to script in a particular category is the transformation of data. 

3. 5. 8 Oracle Stored Procedures 

Both Bulk and Line mode dart scripts utilize Oracle PL/SQL procedures. Every monk DART 
script declares a specific stored procedure and assigns it to a connection handle variable. Bulk 
mode dart scripts call Bulk mode stored procedures, and Line mode DART scripts declare Line 
mode stored procedures. DART scripts then map required and relevant data to the outbound data 
structure (ETD). The data collected by the outbound data structures are then assigned to unique 
parameters in the stored procedures. 
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Each line mode within the Oracle PL/SQL stored procedure implements 1 parameter, which 
consists of a single row of data. Each data segment is processed individually, then the stored 
procedures exit after performing an insert or an update operation. 


3.6 ECARS 2.0 Database 

The ECARS 2.0 Database is an Oracle 8i database with multiple schemas within the instance. 
Currently, the schemas include ones for transaction, transaction reference, geographic, 
Group/Branch, vehicle, and rates pricing engine data. 

3.7 Rates Pricing Engine 

The Rates Pricing Engine is responsible for detennining rental rates for given input parameters. 
The functionality has been written using Pro*C with the ECARS 2.0 database. The Rates Pricing 
Engine functionality will be accessed by the ECARS application using UNIX based Tuxedo 
services. 
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Appendix A - Further Reading 

Web Application 

Exception Handling 

\\FSCORP00\corp public\APPS\Ecars 20\Program Artifacts\Architecture Program Artifacts\Pesign 
Guidelines\Exception Handling.doc 


\\FSCORP00\corp_public\APPS\Ecars 20\Program Artifacts\Architecture Program ArtifactsVDesign 
Guidelines\Logging Guidelines.doc 

Internationalization 

\\FSCORP00\corp pubIic\APPS\Ecars_20\Program Artifacts\Architecture Program ArtifactsVDesign 
GuideHnes\Internationalization Guidelines.doc 

eLocation 

\\FSCORP00\corp public\APPS\Ecars _20\Pevelopment Proiects\Reservation Primary Use Cases\Artifacts\OQ 
Modeling\Elocale\ELocationPOC.doc 

WFSCORPOQVcorp public\APPS\Ecars_20\Development ProiectsVReservation Primary Use Cases\Artifacts\OQ 
Modeling\ElocaIe\ELocation Overview.doc 

Printing * 

\\FSCORP00\corp public\APPS\Ecars_20\Development ProiectsVReservation Primary Use Cases\Artifacts\OQ 

Modeling\Print\Print Overview.doc 
Application Locking 

\\FSCORP00\corp public\APPS\Ecars 2Q\Pevelopment Proiects\Application Navigation and 
Securitv\Artifacts\OQ Modeling\Service Catalog - Application Locking.doc 


ECARS 2.0 to ECARS 1.0 Synchronization 

\\FSCORP00\corp public\APPS\Ecars_2Q\Program ArtifactsXArchitecture Program ArtifactsXApplication Interface 
Processes\Reservation Rental GUI to Legacy Supportdoc 
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Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the Bill to screen used in 
Reservation and Open. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 

2. Screen Prints 
2.1 Main Screen 


'5 Bill-To ~ Microsoft Internet Explorer provided by Enterprise Rent-a-Car 


DRIVERS 


James Atteberry 
Additional Drivers: 2 


REFERRAL 


Account Name 
Contact Name 


DATES/ RATES 


08/27/2001; ECAR 
Daily Rate; ASD 


BILL-TO 


Account Name 
Contact Name 


VEHICLE/SHOP 


1997 Dodge Avenger 
ES 

Shop Account Name 


Notes Taken; 1 

Changed: 
08/27/2001 



Bill-To 


r Bill-To 

Account Name 


Account Number 


-Select- 


Contact Name 


-Select- 


r Vehicle Authorization 

Start Date Start Time End Date End Time No, of Days 


mm 



Phone Number 


12:00 AM 


MM/DD/YYYY 

Daily Amount 



MM/DD/YYYY 

Tax Authorized By 


[ PLUS TAX 


[-Sele ct- 


Status 


Legacy Auth. Amount: $26/DAY-$80QMAX 
Claim Type Insured Name 


Claim/Pol/PO/RO 


PENDING 


INSURED 


r Maximum Information 

Max Per Day Total Max Amount Max # Days 


Last Day 


MM/DD/YYYY 


r Other Authorizations - 



.1 


Tkt- 234567 Cbk- 363221 


Figure 1 - Bill-To main screen 
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IN 

ru 


2.2 


Account Search 


jj Account Search - Microsoft Internet g^farerprovaffiby^e^^^ 


Account Search 


Group: 


01 -Si. Louis 


Account Name 


Account Phone Number 


Account Type 


All 


"3 


Search- j : figset 


Back 



Account Narot-' - /\ 

1 >r Account 

Account 

!^yii« v ',vV.k..A , 0 *^ <s ^ < ,s 

' - SP/BR Account Address 




Phone Numbers 


A ^Hector's Bookstore** 

GE1658 

Corporate 

0101 

6275 Deimar 

St. Louis 

MO 

63130 

(314)721- 
6127 


A.f.i, Remodelinq Co** 

GE1225 

Corporate 

0102 

312 Oak Pic. Village Dr. 

Wildwood 

MO 

63040 

636 458-1552 


Accent Lincoln-met cury** 

129498 

Dealership 

0103 

9700 Manchester Rd 

St Louis 

MO 

63119 

(314)968- 
5300 

o ; 

Advantaae Decoratina** 

GEQ353 

Corporate 

0104 

1601 North 7th St. 

St. Louis 

MO 

63102 

(314)436- 
1419 

0 

African Amer, Rite Of Passaqe** 

GE1538 

Corporate 

0105 

325 Debaiiviere 

St. Louis 

MO 

63112 

314 3612268 

ry 

ft* ; 

Ahzad Boqosian** 

GEQ330 

Corporate 

0106 

7743 Arthur 

St. Louis 

MO 

63117 

(314)645- 
3076 

; 

■CSS t 

Aiq-cs** 

GE023S 

Corporate 

0107 

1 20 S Central, Ste 300 

St Louis 

MO 

63105 

(000) 000- 
0000 

H 1 

A!-pac, Inc.** 

GE1350 

Corporate 

0108 

18535 Old Hwy 66 

Pacific 

MO 

63069 

(636)271-8222 ' 

yJ | 

Albertin Auto Body Inc** 

608868 

Bodyshop 

0109 

8449 Page 

St Louis 

MO 

63130 

(314)423- 


Items 1 - 66 of 66 found 


Pjml2 3 45 Next 


Tkt - 234567 


Cbk - 363221 


: Local intranet 


Figure 2 - Account Search (Open Ticket version) 
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_ 
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Account Name 


Naming Tgpfe ^ V GP/gft AkMmt Address ' " Ctf»; > State Zfo Phone Numbers 


A Collector's Bookstora^* 


6E1658 Corporate 0101 6275 Delmar 


St, Louis MO 63130 (314)721- 

6X27 


A.f.i. Remodeling Co** 


GE1225 Corporate 0102 312 Oak Pk. Village Or. Wildwood MO 63040 636 458-1552 


Accent Uncoln-roercmv ' 


129498 Dealership 0103 9700 Manchester Rd 


St Louts MO 63119 (314)968- 

5300 


Advantage Decorating** 


■3E0853 Corporate 0104 1601 North 7th St. 


St. Louis MO 63102 (314)436- 

1419 


African Arner. Rite Of Passage** GE1538 Corporate 0105 325 Debalivtere 


St Louis MO 63112 314 3612268 


Ahsad Bogosian** 


OE0830 Corporate 0106 7743 Arthur 


St. Louis MO 


63117 (314) 645- 
3076 


GE0238 Corporate 0107 120 S Central, Ste 300 StLouis MO 63105 (000)000- 

0000 


Al-pac, Inc.** 


GE1350 Corporate 0108 13535 Old Hwy 66 


Pacific 


MO 63069 (636)271-8222 


Albertin Auto Bodg Inc** 


Q08863 Bodyshop 0109 8449 Page 


StLouis MO 63130 (314)423- zl 


Items 1 - 66 of 66 found 


Prev 1 2 3 4 5 Next 


Res - 411781 


Tkt - 234567 


Cbk - 363221 


•Ideal intranet 


ir 

■ ^ 


Figure 3 - Account Search (Res Pilot version) 
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Not on File 


Name: 


Address; 


Zips 


City: 


r 


Contact Last Name: 


Phone: 


State: 


Contact First Name: 


.... tlillif 



2.4 Add Contact 


Add Contact 


Last Name: 


First Name: 



Confidential ©<Company Name> 9 2000 Page 13 of 37 

Y:\GROUPS\E-Commerce Group\Patent Materials 831_01\Copy of All Patents\ECARS20 - 
Reservation\Supplemental Specs\Bill-To Screen Spec.DOC 


<Project Name> 
Supplementary Specification 


Last Saved: 
30 November 2001 9:18 AM 


2.5 Rates Table 






¥ Rate M eaqe 


■ ' ''- - -S^l^i 



' it?" 

CCAR 

9.99 250 

29.99 500 

99.99 2500 

2.99 

0.25 

ECAR 

15.99 250 

34.99 500 

109.99 2500 

3.99 

0.25 


FCAR 

20.99 250 

39.99 500: 

209.99 2500 

4.99 : 

0.25 

.SCAR 
i 

25.99 250 : 

. 44.99 . 500 

IS 

. 249,99. 2500J 5.99 

111 

0.25 ! 


3. Reservation Number 

3.1 SUPLpending1.pending2 Behavior 

This area shows the unique reservation number that has been assigned to the newly created reservation. 
The reservation number is 6 alphanumeric characters long. If another reservation is open, its reservation 
will be displayed in this area as well. The user will have the ability to have up to 3 reservations open at a 
time. A hyperlink will be available on the reservation numbers of the reservations that are NOT currently 
being displayed. For the reservation that is currently displayed, the reservation nufnber will not have a 
hyperlink available. This is to allow the user to navigate between the open reservations. 

3.2 Validation 

None identified at this time. 

3.3 SUPLpending1.pending5 Business Exceptions 

supplement al spec for exact text. 

3.4 System Exceptions 

None identified at this time. 

4. Bill-to Title Bar Area 
4.1 Behavior 

The option area in the bill-to Title Bar will allow the user to access transaction-wide functions. These 
functions for Reservation are: Options Print, Void and Transfer. The default option is "—Options - 
The user must press the Go button to initiate the selected function. 

The Title bar Button area contains two buttons - a Go button and a Close button. 

The Go button s always active, and is used to initiate a function selected in the Options area. If the 
selected option is "—Options -" (the default), nothing should happen. 

The Close button is always active and is used to close the current transaction. The button is labeled with an 
'X\ Pressing this button will cause a confirmation popup to appear, asking the user if they wish to cancel 
the transaction and lose all changes. If the user selects 6 No\ they are returned to the Bill-to screen. If the 
user selects 'Yes', the transaction is closed with no changes saved to the database. 
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4.2 Validation 

None identified at this time. 

4.3 Business Exceptions 

None identified at this time. 

4.4 System Exceptions 

None identified at this time. 

5. Button Line Area 

5.1 Behavior 

The Previous button will take the user to the Dates/Rates screen within the same transaction. 

The Next button will take the user to the Vehicle/Shop screen within the same transaction. 

The Complete button will initiate a save of the transaction. All validations will be performed, returning any 
errors to the user. If there are no errors, the transaction is saved, and the user is returned to the Reservation 
home page. 

5.2 Validation 

None identified at this time. 

5.3 Business Exceptions 

None identified at this time. 

5.4 System Exceptions 

None identified at this time. 

6. Bill-to 

6.1 Account Name 

This is a drop down which displays the "branch short list" of Account Names when the user hits the button 
beside it. Or, if the user begins to type anything in the field, a drop down will automatically appear and 
continue to position to the name most closely matching what has been typed. 

Drop down. If the user selects an account not authorized to bill ("Source only") then the system presents 
message and user can make another selection or clear the field and use "Not on File." 

6.1.1 Business Exceptions 
None. 

6. 1.2 System Exceptions 
None. 

6.2 Account Number 

If the user has selected a name from the drop-down, the corresponding number should appear here. 

Alternatively, the user can enter an Account number in this field. 

Validation of the value in the field is performed when the user selects the "Search" button. 
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If the number isn't a valid account, then the system provides a message. If it is valid, but not billable, then 
the user can make another selection or clear the field and use "Not on File." 

6. 2. 1 Business Exceptions 
None. 

6.2.2 System Exceptions 
None. 

6.3 "Search" button 

If this button is used when an account number is in the "Account Number" field, then it validates the 
account number. 

If not account number is present, then the "Account Search" screen is displayed. 

In the first scenario above, if the account is not valid, a message is displayed. (See Referral Source for up- 
to-date functionality.) 

6. 3. 1 Business Exceptions 
None. 

6.3.2 System Exceptions 
None. 


6.4 "Not on File" Button 

Takes the user a screen to add a bill-to. This should also blank out the Account name and the Account 
number. 

Upon returning from the panel, the name should be in the Account Name field and the Account Number 
should be blank. 

6.4.1 Validation 
None. 

6.4.2 Business Exceptions 
None. 

6.4.3 System Exceptions 
None. 

6.5 Contact Name 

This is a drop-down based on the account name selected above. 

If not account name is selected, then the drop-down should be blank. 

6. 5. 1 Business Exceptions 
None. 

6. 5. 2 System Exceptions 
None. 
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6.6 "New Contact" Button 

This allows the user to add a contact to an account in the event that the name they're looking for is not 
present in the drop-down. 

This pulls up a panel for the user to enter the first and or last name. 

6.6.1 Validation 
None. 

6. 6. 2 Business Exceptions 
None. 

6. 6. 3 System Exceptions 
None. 

6.7 Phone Number 

The user may add or update a number for the contact selected. This number is only saved on the contract. 

Standard phone number formatting. 

6. 7. 1 Business Exceptions 
None. 

6.7.2 System Exceptions * 
None. 

6.8 Overali behavior 

Once an account is selected (either by drop-down or by entering the number manually, the "Bill-to X" 
hyperlink is changed to the name of the account. 

As a bill-to is added, the next "Bill-to X" is added to the list across the top, so as to allow the user to add 
another Bill-to. The maximum number of Bill-tos is four. This functionality will not be available for 
Reservation Pilot since only one bill-to is allowed. 

7. Vehicle Authorization 

7. 1 1 Behavior 

The start date should default to the open date and time of the ticket (either real for an open ticket, or 
projected, in the case of a reservation). 

7.1.2 Validation 

Standard date formatting. 

Must be a date within the range of pickup date and return date. 
Requires a status of "Authorized" 

7. 13 Business Exceptions 
None. 

7. 1.4 System Exceptions 
None. 
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7.2 Start Date Button 

7.2.1 Behavior 

Displays calendar for date selection 

7.2.2 Validation 
Standard date calendar. 

7. 2 3 Business Exceptions 

None. 

7. 2. 4 System Exceptions 
None. 

7.3 Start Time 

7.3.1 Behavior 

If the ticket or reservation is 24 billing cycle, then the value defaults to the p/up time (if available) If no 
pickup time is available, the default value is 'blank'. 

7.3.2 Validation 

This field is only valid for 24 hour billing. If the ticket is calendar day billing, the drop down should not 
work. If 24h billing, then the values are 15 minute increments around the clock. t 

7. 3. 3 Business Exceptions 
None. 

7. 3. 4 System Exceptions 
None. 

7.4 End Date 

7.4.1 Behavior 

The end date should default blank . 

7.4.2 Validation 

Standard date formatting. 

Must be a date which is equal to or after the Start Date. 
Requires a status of "Authorized" 

7. 4. 3 Business Exceptions 
None. 

7. 4. 4 System Exceptions 
None. 

7.5 End Date Button 

7.5.1 Behavior 

Displays calendar for date selection 
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7.5.2 Validation 
Standard date calendar . 

7. 5. 3 Business Exceptions 
None. 

7 5. 4 System Exceptions 
None. 

7.6 End Time 

7.6.1 Behavior 

If the ticket or reservation is 24 billing cycle, then the value defaults to the same value as the start time 

7.6.2 Validation 

This field is only valid for 24 hour billing. If the ticket is calendar day billing, the drop down should not 
work. If 24h billing, then the values are 1 5 minute increments around the clock. 

7. 6. 3 Business Exceptions 
None. 

7 6. 4 System Exceptions 

None. * 

7.7 No. of Days 

7.7.1 Behavior 

If the start date and end date are completed, this should be filled with the number of days authorized. 

7.72 Validation 

Valid values are 0 and any integer. 

If the user skips end date, the system will determine the date using this value in association with the start 
date. 

7. 7. 3 Business Exceptions 
None. 

7 7 4 System Exceptions 
None. 

7.8 Daily Amount vs. Total Charges Toggle 

7.8.1 Behavior 

User selects one or the other. 

If total charges, then leave daily amount field and tax field blank. 

If the user elects to add information in to the daily amount field or the tax field and the "Total Charges" are 
selected, the system should change the toggle to the Daily Amount. 
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7.8.2 Validation 

If daily (along with authorized status = "authorized"), then authorized amount, tax and authorized by are 
required. 

If total charges (along with authorized status - "authorized"), then authorized by is required. 
****** N0TE 48 ^jj nQt be for Reservation pilot The users wi]] nQt haye the aWHty to choQse tQtaI 
charges. 

7. 8. 3 Business Exceptions 
None. 

7. 8. 4 System Exceptions 
None. 

7.9 Daily Amount Field 

7.9.1 Behavior 

If this field is changed by the user, the system should ensure that the toggle for "Daily Authorization" is 
selected. 

This field can be filled in by the user, or by the "Rate List Button" 

7.9.2 Validation 
Alpha numeric 

7. 9. 3 Business Exceptions 
None. 

7.9.4 System Exceptions 
None. 

7.10 Rate List Button 

7.10.1 Behavior 

Takes the user to a screen to pick a car class from the "Rates Table". The car class and all associated rates 
for the ticket are saved in the ticket, although it doesn't show on the screen. If the rate that is retrieved is 
tiered, then the rate from the first tier is put in the daily amount field and the tier flag is checked. 

7.10.2 Validation 

If the bill-to does not have negotiated rates in the system, this button will return nothing. 

7. 10. 3 Business Exceptions 
None. 

7.1 OA System Exceptions 
None. 

7.11 Tier Flag 

7.11.1 Behavior 

System updated based on the criteria listed in the Rate List Button behavior. 
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7.11.2 Validation 
None. 

7.713 Business Exceptions 
None. 

7.11.4 System Exceptions 
None. 

7,12 Tax 

7.12.1 Behavior 

Drop down to indicate either "included" or "plus tax". Should default to "included." 

7.12.2 Validation 

This field is required with a daily authorization when the status is "authorized." 

7.12.3 Business Exceptions 

.{335. 

w None. 


r ia 2 

x :i r. 


i U 


System Exceptions 
None. 

7.13 Authorized By 

7.73.-/ Behavior 

Drop down of all of the contacts for the bill-to. See Contact name. 

7.13.2 Validation 

Authorized by is required when the authorization status is "Authorized" 

7.13.3 Business Exceptions 
None. 

7.13.4 System Exceptions 
None. 

7.14 "New Contact" Contact Button 

See New Contact from Bill-to. 

7.15 Output field for Green Screen ECARS Max Amount Field 

7.15.1 Behavior 

This is an output field that displays the information from the Max Amount Field in the Reservation / Open 
Ticket. 

It cannot be updated by the user. 

Anytime the contract is saved, this field is updated with the values from the Daily Amount concatenated 
with the Total Max Amount and saved to legacy that way. If both of those fields are blank, then no update 
is made. 
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7.15.2 Validation 
None 

7.15.3 Business Exceptions 
None 

7.15.4 System Exceptions 
None 

7.16 Status 

7.16.1 Behavior 

The default value is 'blank'. 

The user can select one of the following: Authorized, Pending, Declined, Terminated, and Reimbursement. 

7.16.2 Validation 

If the user selects Authorized, then some fields in the authorization information box are required. See those 
fields for those notes. 

7.16.3 Business Exceptions 
None. 

7.16.4 System Exceptions * 
None. 

7.17 Claim Type 

7.17.1 Behavior 

Drop-down. The user can select from among "Insured, Claimant, or Theft. (Equivalent values will be 
determined for each country.) 

Default to "blank". 

7.17.2 Validation 

This field is required when the rental type is "Insurance". 

7.17.3 Business Exceptions 
None. 

7.17.4 System Exceptions 
None. 

7.18 Insured Name 

7.18.1 Behavior 

This is a text field. 

7.18.2 Validation 
Optional. 
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The bill-to account may require that information be captured in this field (AASI02), but it is only required 
at the time of close. The account may, however, require that any information in the field be in a particular 
format. This is to be enforced during Reservation, Open and Close. 

7.18.3 Business Exceptions 
None. 

7.18.4 System Exceptions 
None. 

7.19 Claim/Pol/PO/RO# 

7.19.1 Behavior 

This is a text field. 

7.19.2 Validation 
Optional 

The bill-to account may require that information be captured in this field (AASI02), but it is only required 
at the time of close. The account may, however, require that any information in the field be in a particular 
format This is to be enforced during Reservation, Open and Close. 

7.19.3 Business Exceptions 

None. * 

7.19.4 System Exceptions 
None. 

8. Maximum information 

8.1 Overall behavior 

8.2 Max Per Day 

8.2.1 Behavior 

This is a numeric field which must support the local currency formatting. 

8.2.2 Validation 

This field is not required. 

8. 2. 3 Business Exceptions 
None. 

ft 2. 4 System Exceptions 
None. 

8.3 Total Max Amount 

8.3.1 Behavior 

This is a numeric field which must support the local currency formatting. 
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8.3.2 Validation 

This field is not required. 

8. 3. 3 Business Exceptions 
None. 

8. 3. 4 System Exceptions 
None. 

8.4 Max # Days 

8.4.1 Behavior 

This is a numeric field which must support integers. 

8.4.2 Validation 

This field is not required. 

8. 4. 3 Business Exceptions 
None. 

8. 4. 4 System Exceptions 
None. 

8.5 Last Day 

8.5.1 Behavior 

This is a date field. 

8.5.2 Validation 

This field is not required. 

8.5.3 Business Exceptions 
None. 

8. 5. 4 System Exceptions 
None. 

8.6 "Last Day" Calendar button 

8.6.1 Behavior 

Displays calendar for date selection 

8.6.2 Validation 
Standard date calendar. 

8. 6. 3 Business Exceptions 
None. 

8. 6. 4 System Exceptions 
None. 
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9. Other Authorizations 

9.1 Overall behavior 

This section will be omitted from Reservation Pilot. It will only be incorporated once the Perot 
system has been integrated. 

9.2 Item 

9.2.1 Behavior 

Drop-down to select from the products available at the renting branch. 

9.2.2 Validation 
None. 

9.2.3 Business Exceptions 
None. 

9. 2. 4 System Exceptions 
None. 

9.3 Start Date 


9.3.1 Behavior t 

The first date which is authorized to bill for the item. This should default to the start date in the 
Authorization Information above. 


9.3.2 Validation 
Standard date formatting. 

01 Must be a date within the range of pickup date and return date. 

1 Requires a status of "Authorized" 

9.3.3 Business Exceptions 
None. 

9.3.4 System Exceptions 
None. 

9.4 End Date 

9.4.1 Behavior 

The end date should default to the end date of the authorization above. Provided that it is the same, when 
the end date of the "master authorization" is changed, the end date should change for each item with a 
matching end date. 

9.4.2 Validation 

Standard date formatting. 

Must be a date which is equal to or after the Start Date for the item authorized. 
Requires a status of "Authorized" 
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9. 4. 3 Business Exceptions 
None. 

9. 4. 4 System Exceptions 
None. 

9.5 Amount 

9.5.1 Behavior 
Text field. 

9.5.2 Validation 
None. 

9. 5. 3 Business Exceptions 
None. 

9.5.4 System Exceptions 
None, 

9.6 Tax 

9.6.1 Behavior 

Drop down to indicate either "included" or "plus tax". Should default to "included." 

9.6.2 Validation 

Required for each row where an item is selected. 

9. 6. 3 Business Exceptions 
None. 

9. ft 4 System Exceptions 

None. 

1 0. Account Search Screen 

10.1 Overall Note 

This screen is called from the Bill-to screen. These notes are intended to highlight to overall functionality, 
but may not reflect the most up-to-date changes. See the use case and screen spec for Search for the most 
accurate information. 

10.2 Group 

10.2.1 Behavior 

This is a drop-down to limit the scope of the search. For Reservation Pilot, this drop down will not be 
enabled. It will be set to the Physical Terminal's physical location and the user will not be able to change 

It 

10.2.2 Validation 

Any group present in the drop down is valid for search. 
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10.2.3 
10.2.4 

10.3 

10.3.1 

10.3.2 


10.3.3 

y 10.3.4 

\ u 

w 
n 

C] 10.4 

3 , 3 

3 3 
J*" 

Of yo.4.2 

O 

ISC 
s s 

10.4.3 
10.4.4 

10.5 

10.5.1 


Business Exceptions 
None. 

System Exceptions 
None. 

Account Name 

Behavior 

The information in the text field is used in association with the "Account Phone Number" and "Account 
Type" to limit the scope of the search. 

Validation 

The field is optional. 

The field defaults to blank. 

Business Exceptions 
None. 

System Exceptions 
None. 

Account Phone Number * 

Behavior 

The information in the text field is used in association with the "Account Name" and "Account Type" to 
limit the scope of the search. 

Validation 

The field is optional 

The field defaults to blank. 

Business Exceptions 
None. 

System Exceptions 
None. 

Account Type 

Behavior 
Drop down. 

The information is used in association with the "Account Phone Number" and "Account Name" to limit the 
scope of the search. 

Validation 

The field is optional. 

The field defaults to "All". 
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10.5.3 Business Exceptions 
None. 

10.5.4 System Exceptions 
None. 

10.6 Search Button 

10.6.1 Behavior 
Executes the search using the criteria entered above. 

10.6.2 Validation 
None. 

1 0. 6.3 Business Exceptions 
None. 

10.6.4 System Exceptions 
None. 

10.7 Reset Button 

101.1 Behavior t 

Clears the screen of the previous search (if applicable) and clears the "Account Name", "Account Phone 
Number", and "Account Type" fields. 

10.7.2 Validation 
None. 

10.7.3 Business Exceptions 
None. 

10.7.4 System Exceptions 
None. 

10.8 Cancel Button 

10.8.1 Behavior 

Returns to the screen from which the search was called. No account name or number is returned. 

10.8.2 Validation 
None. 

10.8.3 Business Exceptions 
None. 

10.8.4 System Exceptions 
None. 


Last Saved: 
30 November 2001 9:18 AM 
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1 0.9 Print Current Page 

10. 9.1 Behavior 

Prints the list of accounts found and shown on the screen. 

10.9.2 Validation 
None. 

10.9.3 Business Exceptions 

None. 

10.9.4 System Exceptions 
None. 

10.10 Print Current Page 

10.10.1 Behavior 

i - 

P :! Prints the list of all accounts found that match the given criteria. 

~ 3 
•SIS 57 

O 10.10.2 Validation 
' w None. 


J** 

■■•as sr. 


P 70.70.3 Business Exceptions t 
s l None. 

* 10.10.4 System Exceptions 
;= | None. 

1 0.1 1 Page Numbers (Hyperlinks) 

10.11.1 Behavior 

Positions the list to the page selected, or to the "Previous" or "Next" page, if selected. 

10.11.2 Validation 

These should not be hyperlinks, if no more than one page of Accounts were returned. (i.e. If only one page 
of accounts is displayed, then the "Prev", "Next" will display on either side of the number "1", and none of 
them will be hyperlinks.) 

10. 11.3 Business Exceptions 
None. 

10.11.4 System Exceptions 
None. 

11. Not on File 

11.1 Note 

International considerations have not yet been made. 
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11.2 Name 

11.2.1 Behavior 

Text field to enter the name of the company. 

11.2.2 Validation 

This field is required. 

11.2.3 Business Exceptions 
None. 

11.2.4 System Exceptions 
None. 

11.3 Address 

11.3.1 Behavior 
■j** Text field to enter the company's address. 

0 713.2 Validation 

HI 

All address formatting rules apply. This field is required. 

11.3.3 Business Exceptions 

1 J None. 

I\ 77.3.4 System Exceptions 

MS 

h ; None. 

J 11.4 Zip 

© 77.4.7 Behavior 

3 3 

Text field to enter the company's zip code. 

714.2 Validation 

All address formatting rules apply. This field is required. The zip code can be entered and then the user 
can use the button behind the field to search for the City and State information. Complies with standard 
address formatting, etc... 

714.3 Business Exceptions 
None. 

11 AA System Exceptions 
None. 

115 Phone 

715.7 Behavior 

Text field to enter the company's phone number. 

715.2 Validation 

All phone number formatting rules apply. This field is required . 
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11.5.3 Business Exceptions 
None. 

11.5.4 System Exceptions 
None. 

11.6 City 

11.6.1 Behavior 

Text field to enter the company's city. 

11.6.2 Vaiidation 

All address formatting rules apply. This field is required. 

11.6.3 Business Exceptions 
None. 

m 11.6.4 System Exceptions 
P None. 

jjj 11.7 State 

H 11.7.1 Behavior 

Hi * 

3 .1 Drop-down field to enter the company's state. 

: ; . 11.7.2 Validation 

« » All address formatting rules apply. This field is required. 

ty 

lij 

;» 7 1 7. 3 Business Exceptions 

y i 

None. 


VSB5T 


717.4 System Exceptions 
None. 

1 1 .8 Contact Last Name 

ff.&f Behavior 

Text field to enter an individual's last name. 

11.8.2 Validation 

This field is required. 

11.8.3 Business Exceptions 
None. 

718.4 System Exceptions 
None. 
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1 1 .9 Contact First Name 

11.9.1 Behavior 

Text field to enter an individual's first name. 

11.9.2 Validation 

This field is required. 

11.9.3 Business Exceptions 
None. 

11.9.4 System Exceptions 
None. 

12. Add Contact 
12.1 Last Name 


Q 12.1.1 Behavior 

M 7 ex t field to enter an individual's last name. 

in 

S3 12.1.2 Validation 

Either of the two fields is required. t 

U * 72.13 Business Exceptions 

! ! , None. 

I?? 

lis 

y 5 ! 12.14 System Exceptions 
None. 

H 12,2 First Name 

12.2. 1 Behavior 

Text field to enter an individual's first name. 

12.2.2 Validation 

Either of the two fields is required. 

12.2.3 Business Exceptions 
None. 

12.2.4 System Exceptions 
None. 

13. Rates Table 

13. 1 1 Behavior 

This table displays the car classes and rates for the bill-to account. For display purposes, international 
considerations for tiered rates have not yet been taken into account, although the functionality is described 
in the "Rate List Button" text above. 

The user can select an amount / car class to be authorized by clicking a car class. 
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13.1.2 Validation 
None. 

13.1.3 Business Exceptions 
None. 

13.1.4 System Exceptions 
None. 

14. Rules 
14.1 Tabbing 

Tabbing between fields should be in the order that they are in this document. 

15. Security 

The user must have the appropriate security level to access this screen. 


Q 
lis 

w 


S 5 S 


S - 
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1 6. System Generated Notes Table (as of 6 August, 2001 ) 



Note Text 

When to generate in . 
Reservation 

When to generate 
in Open 

Use Case/5 

ation becomes an open ticket 
reservation has already been 

"Ticket Opened" 


Create 

Oper 

icket is opened, the information 
ference field will be generated as 

Any text within the preference field 


Create 

Oper 

icket is opened, tne text in tne 
icle notes, will be generated as a 

i ext in tne iieid venicte Notes 


Create 

uper 

ition is matched or unmatched to 

Reservation # "XXXXXX was (un) 
matched to Ticket # "XXXXXX". 


Create/Edit 

Oper 

ttion is created 

"Reservation Created" 

Create 


Creat 

marks tfie ARMS Status Dialog 
lenter His Been Contacted" 

"Renter Has Been Contacted" AND any 
text entered in the ARMS Notes field 

Edit 


XT * i * / 

Navigation/ 
Dialog I 

marks tjp ARMS Status Dialog 
lenter Sis Not Been Contacted" 

"Renter Has Been Contacted" AND any 
text entered in the ARMS Notes field 

Edit 


Navigation/ 
Dialog I 

rvation Jfck-up date is changed 

5 

Pick-up Date "XX/XX/XXXX" was 
changed to "XX/XX/XXXX" 

Edit 

Create (if selected 

in the 
Reservation) /Edit 

Rates/D; 

rvation "^Pick-up time is changed 

5! 

Pick-up Time "XX: XX" was changed to 
"XX: XX" 

Edit 

Create (if selected 

in the 
Reservation) /Edit 

Rates/D; 

Wj-; 

rvation pck-up method is 

II i 

Pick-up Method "XX" was changed to 
"XX". 

Edit 

Create (if selected 

in the 
Reservation) /Edit 

Rates/D; 

rvation pck-up location is 

Pick-up Location "XXXX" was changed 
to "XXXXX" 

Edit 

Create (if selected 

in the 
Reservation) /Edit 

Rates/D; 

rvation Return date is changed 

Return Date "XX/XX/XXXX" was 
changed to "XX/XX/XXXX" 

Edit 

Create (if selected 

in the 
Reservation) /Edit 

Rates/D; 

rvation Return time is changed 

Return Time "XX: XX" was changed to 
"XX: XX" 

Edit 

Create (if selected 

in the 
Reservation) /Edit 

Rates/Di 

rvation return method is changed 

Return Method "XX" was changed to 
"XX". 

Edit 

Create (if selected 

in the 
Reservation) /cult 

Rates/D; 

Source and/or Account Number 
led 

Rate Source "XXXXX" was changed to 
"XXXXX" 

Edit 

Create (if selected 

in the 
Reservation) /Edit 

Rates/D; 

Type is changed 

Rate Type "XXXX" was changed to 
"XXXX" 

Edit 

Create (if selected 

in the 
Reservation) /Edit 

Rates/D; 

Dlass is changed 

Car Class "XXXX" was changed to 
"XXXX" 

Edit 

Create (if selected 

in the 
Reservation) /Edit 

Rates/D; 
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Note Text •. . 

When to generate in 
Reservation 

When to generate . 
in Open 

Use Case/5 

tte source and car class has been 
le user manually changes any of 
s populated ui the vehicle rate 

What rate values were changed and what 
the old and new values are. 

Create/Edit 

Create/Edit 

Rates/D; 

rvation return location is changed 

Return Location "XXXX" was changed to 
"XXXXX" 

Edit 

Create (if selected 

in the 
Reservation) /Edit 

Pick-u 
Locati< 

ip or Branch of the Reservation 
Dcation is changed 

Pick-up Location "GPBR" was changed 
to "GPBR" 

Edit 

Create (if selected 

in the 
Reservation) /Edit 

Pick-u 
Locati* 

ip or Branch of the Reservation 
ation is changed 

Return Location "GPBR" was changed to 
"GPBR" 

Edit 

Create (if selected 

in the 
Reservation) /Edit 

Pick-u 
Locatic 

m has populated the products 
a rate spwce has been chosen 
ser manpflly changes any of the 

SSi 

-ft . f «| 1111 

What values were changed and what the 
old and new values are. 

Create/Edit 

Create/Edit 

Products 
Discoui 

changesji tax or surcharge. 

.is??. 

What values were changed and what the 
old and new values are. 

Create/Edit 

Create/Edit 

Tax 

change^lhe tax-exempt status. 

- ■} 

Tax Exempt Status "XXXX" was changed 
to "XXXX". 

Create/Edit t 

Create/Edit 

Tax/Dri 

chooses^ "Rent" when a renter 
"Rented Warning" 

"Renter Warning overridden" 

Create/Edit 

Create/Edit 

Basic Res/": 

chooseCtb bypass the warning 
Tver's is either over 70. 21- 
20 year&^f age. 

"Underage/Overage warning overridden" 

Create/Edit 

Create/Edit 

Basic Res/1 

changed kny phone number of 
or an aplitional driver. 

What Values were changed and what the 
old and new values are. 

Create (if populated by 
Driver search)/Edit 

Create (if data 
exists from the 
reservation) /Edit 

Basic Res/I 

changes any renter or additional 
irst or last name 

What values were changed and what the 
old and new values are 

Create/Edit 

Create/Edit 

Basic Res/i 

adds or deletes an additional 

Driver "Last Name, First Name" was 
removed 

Create/Edit 

Create (if data 
exists from the 
reservation) /Edit 

Basic Res/! 

changes the Referral Account 

Referral Account "XXXXX" was 
changed to "XXXXXX" 

Edit 

Create (if data 
exists from the 
reservation) /Edit 

Referr 

changes the referral contact, 
rral account is the same) 

Referral Contact "XXXX" was changed 
to "XXXX" for Referral Account 
"XXXX" 

Edit 

Create (if data 
exists from the 
reservation) /Edit 

Referr 

adds a "not on file" contact 

Not on File Contact "First Name, Last 
Name" was added for Referral Account 
"XXXXX". 

Create/Edit 

Create/Edit 

Referr 

changes the bill-to account. 

Bill-to "XXXX" was changed to 
"XXXX". 

Edit 

Create (if data 
exists from the 
reservation) /Edit 

Bill-* 

changes the bill-to contact. (The 
count is the same) 

Bill-To Contact "XXXXX" was changed 
to "XXXX" for Bill-to account "XXXX" 

Edit 

Create (if data 
exists from the 
reservation) /Edit 

Bill-* 
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iNOte lext . . , , 

.When to generate in 
Reservation 

XX Tt r 

When to generate 
in Open 

UseCase/S 

adds a "not of file" bill-to 

Not on file contact "First Name Last 
Name was added for Bill-to Account 
"XXXXX" 

Create/Edit 

Create/Edit 

Bill-T 

changes the authorized by 
^ine is lii-io account is tne samej 

Authorized By "XXXX" was changed to 

"WW" -fV>v« Dill A -.-^,,^.4. uwvwn 

aaaa tor Bul-to Account XXXXX 

Edit 

Create (if data 
exists from the 
reservation) /Edit 

Bill-* 

changes the auth status. (The 
coum is xne same j 

The Authorization Status was changed 
trom aaa to aaaa tor Dlll-tO 
account "XXXXX" 

Edit 

Create (if data 
exists from the 
reservation) /Edit 

Bill-t< 

changes the auth %. (The Bill-to 
3 me same ) 

The Authorization % was changed from 
aa to AA tor bin-to Account 
"XXXX" 

Edit 

Create (if data 
exists from the 
reservation) /Edit 

Bill-ti 

changes the Max Per day. (The 
count ls^tne same) 

ia* 

The Maximum Amount Per Day was 
changed trom XX to XX for Bul-to 
Account "XXXX" 

Edit 

Create (if data 
exists from the 
reservation) /Edit 

Bill-* 

change^jhe Max Billable 

The Bltdo account is the same) 

The Maximum Billable Amount was 
changed from "XX" to "XX" for Bill-to 
Account "XXXX" 

Edit 

Create (if data 
exists from the 
reservation) /Edit 

Bill-* 

changes^jfie number of days, 
•to accoHt is the same) 

The number of days was changed from 
"XX" to "XX" for Bill-to Account 
"XXXXX" 

Edit 

* 

Create (if data 
exists from the 
reservation) /Edit 

Bill-* 

dianges^ther the Billing start 
lling start time (The Bill-to 
5 the saike) 

i~= • 

i :: :! 
; -.sir 

The Billing Start Date and Billing Start 
Time changed from "XXXXXX" to 
"XXXXXXXX' for Bill-to Account 
"XXXXX 

Edit 

Create (if data 
exists from the 
reservation) /Edit 

Bill-* 

changed Mther the Billing end 
lling enpime. (The Bill-to 
5 the sains) 

The Billing End Date and Billing End 
Time changed from "XXXXXX" to 
"XXXXXXXX' for Bill-to account 
"XXXXX". 

Edit 

Create (if data 
exists from the 
reservation) /Edit 

Bill-* 

changes the daily rate. (The Bill- 
t is the same) 

The Daily Rate was changed from 
"XXXX" to "XXXX" for Bill-to account 
"XXXX" 

Edit 

Create (if data 
exists from the 
reservation) /Edit 

Bill-* 

:hanges the Authorized Car 
he Bill-to is the same) 

The Authorized Car Class was changed 
from "XXXX" to "XXXX" for Bill-to 
account "XXXXX". 

Edit 

Create (if data 
exists from the 
reservation) /Edit 

Bill-* 

changes the Plus Tax check box 
to account is the same) 

What the check box was and what it was 
changed to 

Edit 

Create (if data 
exists from the 
reservation) /Edit 

Bill-* 

changes a product or service (The 
the same) 

What Products were added or deleted and 
the amounts they were changed from and 
to. 

Create/Edit 

Create/Edit 

Bill-* 

adds a Not on File Bill-to 

Not on File Account "XXXX" has been 
added as a Bill-to 

Create/Edit 

. /T"» J * j. 

Create/Edit 

Bnl-t< 

changes the Ro/Po/Cl #. (The 
the same) 

The Ciaim/Pol/PO/RO was changed from 
"XXXXX" to "XXXX" for Bill-to 
account "XXXXX" 

Edit 

Create (if data 
exists from the 
reservation) /Edit 

Bill-t. 

changes the Claim type. (The 
the same) 

The Claim Type was changed from 
"XXXX" to "XXXX" for Bill-to account 
"XXXXXX" 

Edit 

Create (if data 
exists from the 
reservation) /Edit 

Bill-t. 
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Note Text : 

When to generate in 
Reservation 

When to generate 
in Open 

Use Case/5 

changes the insured's name. 

The Insured's Name was changed from 
"XXXXXX" to "XXXXXX" 

Edit 

Create (if data 
exists from the 
reservation) /Edit 

Bill-* 


M 

fas?- 
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Screen Action Specification 

1. Introduction 

This document describes the behavioral characteristics associated with the Callback Flag screen, and its related 


screens. 


The system must be able to distinguish, presumably by the terminal ID, the proper screen language presentation as 
well as any field formatting applicable to that particular locale. 

2. Screen Shots 


/|| Callback Indicator -- Web Page Dialog 


i Only items with corresponding information on the 
i reservation are enabled. 


= r! Adjuster - SAFECO INS-ST. LOUIS** 
H Service 
E? Body Shop 

l~ Renter - AKOPYANTS NATALIA S 
Comments: 



ii mi 


Figure 1: Callback Flag Pop-Up 


3. Field Descriptions 
3.1 Callback Flag Main Page 

3. 1. 1 Warning Message Text Field 

3.1.1.1 Behavior 

This is a read-only, static text message to the user. It is providing information to the user regarding the usage of the 
screen. The text should read "Only items with corresponding information on the reservation are enabled'". 

3.1.1.2 Validation 
None identified at this time. 

3.11 .3 Business Exceptions 
None identified at this time. 
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3.1.1.4 System Exceptions 
None identified at this time. 

3.1.2 Adjuster Checkbox 

3.1.2.1 Behavior 

This is a checkbox tha t allows the user to selec t an Adjuster Callback Flag. The user can chec k anv numbe r of the 
checkboxes at a given ti me. If an Ad juster Callback Flag was already selected for a reservation a ndxhaLmsemtion 
was saved/completed, th en the checkbox will be chec ked, but the field will be disabled. The user will not be able to 
unselect it. 

If the user is not allowed to select an adjuster callback because there is not a bill-to entered, then the checkbox will 
tedisahlsL 

3.1.2.2 Validation 

This field is validated bv not allowing the user to select it if the bill-to information is missing from the reservation. 
M^soj/^dmAbyMotM owms: the user to unselect an adjuster callback from a previously completed 
reservation. 

3.1.2.3 Business Exceptions 

There mus t be a Bill-T o associated with the Reservation before an Adjuster Callback Flag can be generated. 

3.1.2.4 System Exceptions 

[fa Bill-To is not associated with the Reservation, then the user will not be able to select the Adjuster Flag. 

3.13 Service Checkbox 

3.1.3.1 Behavior 

This is a checkbox that allows the user to select a Service Callback Flag. The user can check anv number of the 
checkboxes at a given time. If an Service Callback Flag was already selected for a reservation and that reservation 
was saved/completed, then the checkbox will be checked, but the field will be disabled. The user will not be able to 
unselect it. 

If the user is not allowed to select a service callback because there is not a shop entered, then the checkbox will be 

3.1.3.2 Validation 

This field is validated by not allowing the user to select it if the shop information is missing from the reservation. It 
jsalso validate d bv not allowing the user to unselect a serv ice callback from a previously com pleted reservation . 

3.1.3.3 Business Exceptions 

There must be a Body Sh o p associate d with the Reservation before a Service Callback Flag can be generated . 

3.1.3.4 System Exceptions 

If a Shop is not associated with the Reservation, then the user will not be able to select the Service Flag, 

3.14 Body Shoo Checkbox 
3.1.4.1 Behavior 

This is a checkbox that allows the user to select a Body Shop Callback Flag. The user can check anv number of the 
checkboxes at a given time, ff a Body Shop Callback Flag; was already selected for a. reservation and that 
reservation was saved/completed, then the checkbox will be checked but the field will be disabled. The user will 
not be abl e to unselect i t 

Tf the user is not allowed to select a body shoo callback because ther e is no t a shop entered, then the checkbox will 
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be disabled . 


3.1.4.2 Validation 

This field is validated by not allowing the user to select it if the shop information is missing from the res ervation. It 
is also validated bv not allowing the user to unse lect a Body S hop callback 
reservation. 


eservation befo re a Body Shop Callback Fh 


3.1.4.3 Business Exceptions 
There must be a Body S hop associate 

3.1.4.4 System Exceptions 

If a Shop is not associated with the Reservation, then the user will not be able t o select the Service Flag. 
3.15 Renter Checkbox 

3.1.5.1 Behavior 

This is a check bo^tha t allows the user to select a Renter Callback Flag. The u ^ercan^heck any numberofthe 
Shgskhgxesg a *M ven time. If a Renter Callback Flag was already selected for a reservation and that reservation 
wjgjjyjgZsQmfi^^ will be disabled. The user will not be able to 


If the user is not allowed to select a Renter callback (because there is not a renter entered), then the checkbox will be 
disabled. * 


>m the reservation. 
V cpmplet 


3.15.2 Validation 

This field is validate d bv not allowing the user to select it if the renter information is 
It is also validated bv not allowing the user to unselect a Renter callback from a pn 

3.15.3 Business Exceptions 

There must be a renter name associated with the Reservation before a Renter Callback Flag can be generated. 
3.1.5.4 System Exceptions 

If a Renter is not associated with the Reservation, then the user will not be able to select the Renter Flag. 
3.1.6 Adjuster Information Text Field 

3.16.1 Behavior 

This is a read-only, static text message to the user. It provides information to the user regarding the information 
previously entered on the reserva tion screen. It will display the bill-to name that was entered on the bill-to panel of 
the reservation scree n. 

If no bill-to was entered, nothing will display. 

3.16.2 Validation 
None identified at this time. 

3.16.3 Business Exceptions 
None identified at this time. 

3.16.4 System Exceptions 
None identified at this time. 
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3.1.7 Service inf ormation Text Field 

3.17.1 Behavior 

This is a read-only, static text message to the user. I t provides inf ormation to the user regarding the information 
previously ent ered on the re servation screen . Tt will display the shoo name that was entered on the vehicle/shop 

If no sho p was entered, nothing will display. 

3.1.7.2 Validation 
None identified at this time. 

3.1.7.3 Business Exceptions 
None identified at this time. 

3.1.7.4 System Exceptions 
None identified at this time. 

3.18 Bnetv Shoo Information Text Field 
3.1.8.1 Behavior 

This is a read-onlv static text message to the use r. It proyidesjn format ion to th e user r egarding the information 
previously entered on the reservation screen. It wil l display the shoq name that was en tered on the jgrfudfi/shi ffi 
panel of tb^ reservation screen. 

If no shop w as entered nothing wilLdisplsy^ 

3.18.2 Validation 
None identified at this time. 

3.18.3 Business Exceptions 
None identified at this time. 

3.18.4 System Exceptions 
None identified at this time. 

3.1.9 Renter Inform ation Text Field 

3.19.1 Behavior 

Thfc j, a read-only sMjg text mess^e to the » 1S er. It p™viri>, information to the user regarding the information 
previously ente red on the reserva tion screen. Tt will dis play the renter name that was entered on the — - 
the reservation screen. It will he displayed in the format of last name, first name. 

If no renter was entered nnthinc will display. 

3.19.2 Validation 
None identified at this time. 

3.19.3 Business Exceptions 
None identified at this time. 
3.1.9.4 System Exceptions 
None identified at this time. 
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m 

3 


JSS. 


3.1 Comment Text Box 

3.1.10.1 Behavior 

This is a fr ee-form t ext field that allows the user to en ter reserva tion comments about th e callback fla gs that are 
selected. T hese notes appear only on this screen. Thev do not appear in the callback section of legacy . 

3.1.10.2 Validation 
None identified at this time. 

3.1.10.3 Business Exceptions 
None identified at this time, 

3.1.10.4 System Exceptions 
None identified at this time. 

3.1.11 OK Button 


3.1.111 Behavior 

pi When the user presses the 'OK' button, the system saves the callback flag and notes that the user has entered and 
O closes the callback f1a% screen. 


hf The user is perm itted to press the 'OK' button and have no items checked. 


If the Callback F lag screen is navigated to bv virtue of the user com pjgtfflg the reservation, after the user presses the 
'OK* button and the information is validated, the reservation completion process continues. 

1J 3.111.2 Validation 

When the user presses the 'OK' button, the system validates the Adjuster. Body Shop and Service data to insure that 
y the appropriate information fBill-To or Body Sho p^ is already contained within the reservation. 

3.1 .1 1 .3 Business Exceptions 

The user cannot save an adjuster callback fla£ if the Bill-To information is not in the r ej^^tioiuJC he user cannot 
save a Body Shop or Service callback flagifj&e Body Shop information is not in the reservation . 

3.111.4 System Exceptions 

Due to the way that the scree n works with the disabling of invalid options, there should not be the case of the user 
checking an invalid flag. However, if the flags do not valida te, the system will alert the user and return him/her to 
the callback flag screen. 

3.1.12 Cancel Button 
3.112.1 Behavior 

When the user presses the 'Cancel' button, the system closes the Callback Flag screen. 

If the Callback Fla^ screen is navigated to bv virtue of the user completing the reservation, when the user presses the 
'Cancer button the complete reservation process is cancelled and the Callback Flag window is closed . 

3.1.12.2 Validation 
None identified at this time. 

3.1.12.3 Business Exceptions 
None identified at this time. 
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3.1.12.4 System Exceptions 
None identified at this time. 


4. Rules 

• Callback Flag data is only saved to the reservation if al l the changes to the reservations are saved. 

• The user has the o ption t o add/edit callback flags to anv reservation in his/her group . 

• This screen will not be available for NatRes Reservations. 

• The screen will ap pear to the user when he/she starts the completion process of a new reservation and 
from the 'Reservation Callback* option in the ^Options' drop down menu in the title bar. 

• If the user has s *Wted a callback and then edited other reservation information that invalidates the 
callback, the syste m will not save th at particular callback fla p. The user will not be notified of this. 

5. Security 

• ThP ^rnritv for Callback Flag is based upon tfaft Reservation security model. If the user has 
permissions to edit a reservation, he/she will be able to add/edit callback flags In general all users m 
a proup can modify all reservations for thatj^u&_ 

6. Questions 
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Contact Synchronization Document 

1. Introduction 

This document will describe the flow of the Customer Contact Synchronization between the GUI ECARS 
2.0 system and the AS400 legacy system. 


2. Contact Synchronization * Transaction Flow 



Figure 1 - Transaction Flow 
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Cnntant Synchronization Description: 

After the Rental GUI system writes the reservation t ransaction to the Oracle datahase. it will initiate a Java object, 
PCI ResClient. created bv PCI, sending the reserva tion number and whether the transaction was an Add or 
U pdate. 


form the reservatk 


tion data into the 


PCI ResClient will use Rental GUI's 1 
npppssarv input parameters. 

The input parameters will be sent, to a UNIX Tuxedo Service ResService. 

nr.T ResClient will also distribute th* Hats to another Tjj Service- RESSRVR400. on the appropriate AS/400 
machine. 

mechanism will he used between the two Tuxedr. s ervices to manage transaction data. 

R ESSR VR400 P a« the in put narameter s to the wrapper pro gram of the legacy reservation program, CCRSO 1 . 

I Ipon entering the wrapper Proar*"- the in put parameters will he written to a transaction jg| fifo 

The wrapper progra m will perform edits based on business rules and update legacy reservation files on the AS/400, 

When the reservation has been successfully writ ten fa new legacy reservation numbe r is created), the wrapper 
pr noram will writea record to the Rental GUI/Le^ r.v Reservation Number Cro»-igfasnaLfilfi» 

wh«n the, wrappe r program has c ompleted processin g it will write the Input Panmeteawl any errors encountered 
to the transaction log file and return this data to RESSRVR40Q, 

RF.SSR VR400 will return the Input Parameters and e rrors, if applicable, to ResService. It will wrjteji 
regarding anv errors to a log, file on Oracle. 


EERQJ HANDLING: 

Position 99 of the. F.RRORS field represents if the res 


iction was written to the legacy file. 


R ATRRMST. successfully. 

It will return a valne of '0' if the write failed and T ! f *° Sate wag fflfisessAL Position 1 - 98 of the ERRORS 
field represent error codes and the pro- am that, received it. 

The F.RRORS <r» i« ^rat^ into 7 grout * of prmr code (4 char) and procrram d 0 char). The t 
reference error m^aoe description* fmmri within the Wary reservation programs. 

H^criptions can be j^jsjej hv a refer ence file on the AS/400 DEV machine, 
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Other information: 

Unix to AS400 wrappgri 

This modu le accepts contact data fr om the Tuxedo Service (UNIX), performs an appropriate 
passes it on to the contact RPG wrapper program. 


lipulation and 


Create Contact: 

When called by Rent 
bv a Rental Redesign create contact transaction. 

The Create Contact m odule is calle d and validates the existence of the required data. If required data is not present, 
the module will genera te error codes which wil l be logged on the AS/400. 

If the required data is sent the Create Contact module is passed to the AAIDOI wrapper program. 

Only 1 tran saction will b e processed at a time. The Rental Transaction Location Group/Branch number must be sent 

to identify what mac hine a conta ct resides on. 

When the unique contact id# limitation is reached. '999 1 will be assigned. The only issue this creates during 
Reservation is identifying a contact a s 'Unknown' w hen the contact in actuality, is known. For future, this will 
create an issu e during Open Contract i n that a contact id# other than '999. must be identified. 


inversion: 

Contact will be added and maintained from current state using owning group, legacy customer number, transactions 
source machine name , and contact adjuster so urce numb er fheenno^ 

One record per group, customer nu mber, source m achine, and contact adjuster source number (heenno^ will exist in 

Each contact will be assigned a new unique contact sequence number, seq nbr. 
It will be r elated to th e^racle Cus t Mast via the new cust seq nbr 


Logic: 

Create/Add Transaction: 

If Group. Leaacv Customer Number, source machine, and 
transactio n. 


cists ignore the 


If Group. Legacy Customer Number, source machine, and source number (heenno) does not exist, create 
the new Contact and assign a new contact sea nbr _ 


cust seq nbr. 


)racle Cust Mast by group and legacy customer number retrieve the new 
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Error processing needs to be es tablished if referential integrity error is received. 


Re-write o r flag the transaction r ecord so that it is processed again. The tr ansaction re cord re-pr ocessing 
peeds to be limited to a specific number of times so as not to c ause an infinite loo p. Kick out the 
transaction or log the data after the specified number of re-tries. 

Update/Del ete Contact Transaction: 

Retrieve data using lega cy group, legacy custome r number, source machine name, source sequence 
number fhccnno^ 

Update contact information if it changes- 
Delete a contact if it was deleted in legacy 


Contact Data: 

File DRHfSC is updated continuously throughout the day. T he_on}yjrmsa ctions we want to pass, for now, to rental 
are add's, deletes, and changes to co ntact name, st atus, or customer typ e. All other changes ne ed not be sentto 
future state, 
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Screen Action Specification 

1, Introduction 

This document will describe the behavioral characteristics associated with the Daily Reservation Detail 
screen. 


The system must be able to distinguish, from the physical location of the terminal, the proper screen 
language presentation as well as any field formatting applicable to that particular locale. 
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2. Daily Reservation Detail 



Detail Summary | Forecasting [ Motification 


Reservation List for: jEBWI EE 


(MM/DD/YYYY) 


Group: 


Branch: 


Edit Reservation Number: 


1 01 - St. Louis 


I The First Branch 


Date 

"5/5" 


Time 


Renter Name 


Method 


Prckufr Location 


Car Class Prfcferiencg 


Reservation 
Type , 


Washington. George 


DEL 


Front step of City Hail. LCAR 


Corporate 


-a 


5/9 8: 30 AM Atreberrv, James 


W/IN 


SCAR001 


Retail 


5/9 8:45 AM Snuffitelfi, Joe 


P/UP 


Home 


Something with 4 wheels 
ECAR and an engine that won't Insurance 

leak oil, 


5/9 8s 45 AM 2 ukow. Thomas 


DEL/R 


Service garage for Lou 
Fusz Dodge 


Dodge Viper with tow 
package installed 


Dealership 


5/9 1Qi30 AM Antilles, Wedge 


W/IN 


XCAR 


Corporate 


5/9 12i00 PM Solo. Hans 


XCAR 


Anything that can make R eW jj 
the K ess el Run 


5/9 12:15 PM Sraves, Paul 


CWC 


ICAR 


VS engine 


Insurance 


5/9 1:20 PM Jones. Christopher 


P/UP 


County Jail 


No bars in windows 


Government 


5/9 1:20 PM Smith, Chris 


W/IN 


CCAR 


Retail 


NoDate, NoTlme 


W/IN 


Retail 


Total number of reservations; 10 


Tkt - 234567 Cbk - 363221 


Figure 1 - Daily Reservation Detail 
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^R^sewation Detail : - Hicrosott Internet gxplotet pmvlde&bg Entetp^eBentra-4^; 


VBS? 

O 

ill 


IK* 

f i 5 


in 



Detail Summary j Forecasting ) Notification | Search 


Reservation List for: SHE 


in] (MM/DD/YVYY) 


Group: 


Branch: 


Edit Reservation Number: 


|QJ^StLouis_ 


The First Branch 


Picfeup 




^<£?^' 


Reservation 

Date 


> Method ( 



5/9 

Washington, George 

DEL 

Front step of City Hall. 

LCAR 


Corporate 

5/9 

8:30 AM Atteberrv, James 

W/IN 


SCAR001 


Retail 

5/9 

8*45 AM Snuffiteili.Joe 

P/UP 

Home 

ECAR 

Something with 4 wheels 
and an engine that won't 
leak oil. 

Insurance 

5/9 

8 5 45 AM Zukow, Thomas 

DEL/R 

Service garage for Lou 
Fus2 Dodge 


Dodge Viper with tow 
package installed 

Dealership 

5/9 

10:30 AH Antilles, Wedqe 

W/IN 


XCAR 


Corporate 

5/9 

12:00 PM Solo, Hans 



XCAR 

Anything that can make 
the Kessei Run 

Retail 

5/9 

15:15 PM Graves, Paul 

CWC 


ICAR 

V6 engine 

Insurance 

5/9 

i,?nDM Jones. Christooher 

P/UP 

County Jail 


No bars in windows 

Government 

5/9 

1;2QPM Smith, Chris ^ 

W/IN 


CCAR 

^ — , 5 

Retail 


NoDate. NoTime 

W/IN 




Retail 



Total number of reservations; 10 


ill MSB 


Res - 411*81 


Tkt- 234567 Cbk - 363221 


Figure 2 - Reservation Detail - Reservation Pilot version 


3. Group 

3.1 Behavior 

This criterion will he limited t » those wnnns that wrist at anv noint in time for which the search is 

being executed. For reservation n i lot Hmn down will not he enabled Tt will default to the physical 
W.aWs pfflim and the u ^r will not he able, tn .witch branches . The selection of "A 11 is NOT included 
TnTi ^t ,« it wnnld return too larae of a result set . Thi« s^rrh criteria area will be <S drop-down box . Bfi 
n ^r H;on1d a kn like to have the ability t o ^ a character al pha «r numeric into the criteria area and have 
the Hrn p down list no tion to the character. .If the user enters an "H" the drop down list would position to 
the first string beginning with "H" in the list) IJmuMdmmmf™ V™* * hmM default t0 
; group associated to the terminal locale. 
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3.2 

3.3 
3.4 

4. 
4.1 


4.2 


4.3 
4.4 

5. 

5.1 


5.2 


5.3 


Validation 

The items ap pearing in the list are static: the user cannot add items to the list dynamically. This should, in 
some manner, be initially defaulted to the terminal's group, (based on physical location) 

Business Exceptions 

None identified at this time. 

System Exceptions 

None identified at this time. 

Branch 
Behavior 

This search c riterion will be limited to thos e branches that exist, within the group at any point in time for 
which the search is being executed . Th* selection of "All" is NOT included in this selection list as it would 
reftirn too larg e of a result set . This search criteria area will be a drop-down box . The users would also like 
to have the ability to tvne a character, alpha or numeric, into the criteria area and have the drop down list 
position to the character . (If the user enters an "H" the drop down list would position to the first string 
beginning with "H" in the list) 

1 1non initial presentation of the nanel this s h ould default to the branch associated to the terminal locale, 
Rranch items appearing in the list will be limited to the Group item selected . Once the selected Group 
item has chanped. the branch will he set to blanks . This will require the user to select a branch, at which 
time the display area will be refreshed, rep onnlated and repositioned. For Reservation Pilot, the Branch list 
will NOT contain a blank entry. 

Validation 

The items appearing in the list are static: the user cannot add items to the list dynamically,- This should, in 
some manner, be initially defaulted to the terminal's branch, (based on physical location). 
This list will be limited to the branches associated with the group selected. 

Rnsiness Preoptions 

Tf a user does not enter a bra nch, or blanks out this area. anH attem pts to refresh the list an error message 
will he presented. See the "error message" supplemental spec for exact text. 

System Exceptions 

None identified at this time. 

Reservation List Date 

Behavior 

This area will a tmrt field which will allow t h » nser to enter the date for which they want to view 
reservations. The format to e nter is mtnddww * numeric characters without anv delineating characters. 
TW^Iso h* a calendar icon function which u nit alW the user tn <^ct it and he shown a monthly 
calendar for the m to select a date . ( As outlined in the HTML standards for Calendar Controls.) 
Upon initial presentation of the panel this should default to the current date. 

Validation 

Validation w ill occur when the nser submits the form. It 
Please see error messag e supplemental snec for exact text. 

Business Exceptions 

If a user does not enter a date, or bl anks oiit this area, and at 
he presented. See the "error message" supplemental <=p"c for exact text. 


/ear comt 


message wi 


Confidential 


©<Company Name>, 2000 


Page 8 


<Project Name> 

Version: <1.0> 

Supplementary Specification 

Date: <dd/mmm/yy> 

<document identified 


-s 

a 


1»3? 

jjwis 


5.4 System Exceptions 

None identified at this time. 

6. Edit Reservation Number Field 

6.1 Behavior 

This criteria area will be an alphanumeric field . It will not be formatted for presentation purposes . 
When a user enters an alphanumeric string, and selects the edit function, the system will attempt to find an 
exact match for the characters entered, a kn if the user is in the process of entering a reservation, the focus 
will be on the edit function. With the focus on the edit function, if the "enter" kev is selected it will 
operate the same as if the edit function were selected . 

If a single, exact match, is found the system will take the user to the edit/view reservation detail panel. 
For reservation pilot the system will search on ly reservations created within the Physical Terminal 
location's gro up number. 

6.2 Business Exceptions 

Tf no matches are found the system presents a message. See error message spec for exact text. 

Tf there are two or more matches found, the system displays the results as a display list exactly as described 
in the Reservation Search results display area. (Included below for clarity) 

Multiple Result Display Criteria - Identical to Search Result Display 

This display area provides the user with the search result list. The result list will be comprised of 8 static 
columns. The specific column order is: 

1) The group number and branch number will be concatenated to form this column. 

2) The pick up date is the next column, formatted by locale. 

3) The pick up time is the next column, formatted by locale. 

4) The renter's last name and first name will be concatenated to form this column. 

5) The pick-up method. 

6) The car class. 

7) The reservation type. 

8) The reservation number. 

The display presentation for each type of information will adhere to result list standards. 
The default sort order is: 

1) Pick-up group and branch, in numeric ascending order. 

2) Pick-up date, in chronologically in ascending order. 

3) Pick-up time, in chronologically ascending order. 

For date and time sorting the following will be the standard: 

1 . Reservations with a date, but no time. 

2. Reservations with a date and a time. 

3 . Reservation with no date, but have a time. 

4. Reservations with no date and not time. 

4) Renter last and first name, in alphabetically ascending order of last name. 

ThP mm would like to haye the ability tn *ort the colum n, in both ascendino and descending order. This 
^Tort the entire resul t ,et When a colu mn is selected to ^rtnll ™ ^nndarv sor t c r i t eri a is 

oh»nH/in«d The manner in which Oracle sort, .cedin g and descending values will be used, The disp lay 
area will position to the to p of the e ntire result list ™ fhf > ™ ] "™ elected to sort. 

Tf the user moves f orward or bac kward within the result list the sort will Still be in effect. 

j reservation from the 
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result list, and perform a simple task, (a. function button, icon, mouse clicks which would then open the 
reservation for editing purposes. Within this display list the user would select the Renter Name from the 
dis play list a nd perform the designat ed function. This would he contingent upon the user having the 
ap propriate security to ed it the reser vation selecte d. This functionality will be consistent and standard 
throughout the application. 


6.3 System Exceptions 

None identified at this time. 


7. Reservation Display Area 

7.1 Behavior 

The dis play area will initially be defaulte d to all reservations, for the default group, branch and date, 
positioned to where the pick u p time is wit hin a time fram e of the current time less 30 minutes. All of the 
reservations for t he group, branch and date will be returned for display, however the system will position 
the list to th e reservation with the c urrent time less 30 minutes. 
Further elaboration/rules about how th e dis play wil l position to a reservation follows: 
1 ^ If there are not anv reservati ons for the 30 minute time fr ame. AND there are reservations with the date 
but no time, the list will be positioned to the first reservation without a time. 

7Mf there are not a nv reservations for the 30 min ute time frame^hiit there a reservation between the ■>() 

the future wh ich is closest to the current time. 
^ If there are not anv reservations for the 30 minute time frame- AND there are not anv with dates and no 
time, the system will position to the reservation in the fhture which is closest to the current time. 
4^ f f there are not anv reservati ons for the 30 minute time frame, AND there are not anv with dates and no 
rime. AND there are not anv i n the future, the system will position to either the first reservation with no 
date hut has a ti me, or if none of those exis t- the system will position to the first reservation without a date 
and without a time, if anv exist 

Examples: 

1) If the user signs on at 8:00 A.M., and there are not any reservations for 8:00 A.M. or before, and there 
are reservations with the date but without a time, the list will be positioned to those reservations without a 

^If the user signs on at 8:00 A.M., and there are not any reservations for between 7:30 and 8:00 A.M., but 
there is one for 7:15 A.M., and 8:15 A.M., and there are reservations with the date but without a time, the 
list will be positioned to the reservation in the future which is closest to 8:00 A.M., which is the 8: 15 A.M., 

reservation. joaaax* a 

3) If the user signs on at 8:00 A.M., and there are not any reservations for between 7:30 and 8:00 A.M., ana 
there are reservations with the date but without a time, but there is one for 8:15 A.M the list will be 
positioned to the reservation in the future which is closest to 8:00 A.M., which is the 8:15 A.M., 

reservation. joaaaa/t a 

4) If the user signs on at 8:00 A.M., and there are not any reservations for between 7:30 and 8:00 A.M., ana 
there are no reservations with the date but without a time, and there are not any reservations for a future 
time, the system position to those at the bottom of the list, the first reservation without a date but with a 
time, and if none of those exist, it will position to the first reservation without a date and without a time. 

The scroll bar will be enabled to allow t he user to ac^ss *H reservations. 

The result list will he comprised of 7 static columns. The specific column order is: 

1) The pick up time is the first column, formatted bv locale. 

2) The renter's last name and first name will he concatenated to form this column. 
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3) The pick-up method. 

4) The pick-un location. 

5) The car class. 

6) Preference. 

7) Rental Type. 

Sort order of the list will be: 

Reservations with a date, but no time. 
Reservations with a date and a time. 

The result list wil l display the reserve 

time frame. 


7.2 

7.3 
7.4 


Reservations with no date an d not time. 

The users would like to have the ability to sort the column s in both ascendinp and descending order. This 
will sort the en tire result set. When a column is selected to sort all other default, or secondary sort criteria is 
ahandoned. The manner in which Oracle sor ts ascending and descending values will be used- The display 
area will position to the ton of the entire result list based on the column selected to sort. 
If the user moves forward or backward w ithin the result list, the sort will still be in effect. 

The capability also needs to evist where a us e r nan indicate or select an individual reservation from the 
remit list, and perform a simple task, (a. function button, iron mouse clicks which would then open the 
reservation for editing numoses Within this d isplay list the user would select the Renter Name from the 
display list and perform the designated function This w onM he contingent upon the user having the 
a pnronriate security to edit the reservation selec t ^ This functionality will he consistent and Standard 
throughou t the application- 
Validation 

The user mav not select to edit a reservation that is outside of t heir security boundaries. If the user changes, 
the ff oup and the branch is positi oned to blanks, the result list should be cleared also. 

Business Excel 


•MM I 


System Exceptions 

None identified at this time. 


8. Results Feed back Line Area 

8.1 Behavior 

Thk feedback area provides the user with the tota l number of relations for the day. If there are 1 50 
reservations for the gr™ T with or withou t pickup time and then others witho ut dates , the 

total shown would include all 1 50 which have the pacific date, whether or not a pick-up time is specified, 
pins those without a date. 

8.2 Validation 

None identified at this time. 

8.3 Business Exceptions 

None identified at this time. 

8.4 System Exceptions 

Buttons would be enabled appropriately for list display area. 
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9. Button Line Area 

9.1 Behavior 

The Print List image/hutton will print the enti re list of reservations for the dav. 

The Refresh image/button will reposition the entire list to the current time less ^0 minute time frame. 
The New Reservation button will create a n*w reservation, changing the screen to that reservation. 


9.2 Validation 

None identified at this time. 

9.3 Business Exceptions 

None identified at this time. 

9.4 System Exceptions 

None identified at this time. 


10- Rules , 

Tvpps of reservations, f or the defaulted q mnp and branch or the selected pronn and branch, which will not 
frejncluded in the displays are: 

• Voided Reservations. 

• Reservation s transferred t o another branch. 

© Reservation that have been attached to ™ open ticket. 
The refresh will be a manual process, no automatic refresh will happen while theug erjs on this_ paneL 

11. Security 

The user must have the appropriate security 1pv*1 to access this screen. TMuser is allowed toyjm^XJPJml 
anything. It is when thev attempt to edit a reservation that their security restrictio ns will be enforcecL 


Confidential 


©<Company Name>, 2000 


Page 12 


<Company Name> 


□ SUBJECT \* MERGEFORMAT □ ECARS 2.0 - Daily 

Reservation SummaryD 
Screen Action Specification 


<Project Name> 

Version: <L0> 

Supplementary Specification 

Date: <dd/mmm/yy> 

<document identified 


Revision History 


Date 

Version 

Description 

Author 

5/15/2001 

1.0 

Created Document 

Johnny S. Johnston 

5/29/01 

1.1 

Updated for list display resolution 

Johnny S. Johnston 

09/04/2001 

1.2 

Updated to reflect changes from Navigation 
use case 

James Atteberry 

10/03/2001 

1.3 

Added screen shot from Reservation Pilot 
version. 

James Atteberry 

10/26/2001 

w 

1.4 

Clarified Branch list behavior for 
Reservation Pilot 

James Atteberry 


Confidential 


©<Company Name>, 2000 


Page 2 


<Project Name> 

Version: <L0> 

Supplementary Specification 

Date: <dd/mmm/yy> 

<document identified 


Table of Contents 


□ TOC\o"l-3"-l. 

2. Daily Reservation Summary 

3. Group 

3.1 Behavior 

3.2 Validation 
3.3 
3.4 


Business Exceptions 
System Exceptions 


4. Branch 


4.1 Behavior 

4.2 Validation 

4.3 Business Exceptions 

4.4 System Exceptions 


5.1 Behavior 

5.2 Validation 

5.3 Business Exceptions 

5.4 System Exceptions 

6. Reservation Display Area 

6.1 Behavior 

6.2 Validation 

6.3 Business Exceptions 

6.4 System Exceptions 


7.1 Behavior 

7.2 Validation 

7.3 Business Exceptions 

7.4 System Exceptions 

8. Button Line Area 

8.1 Behavior 

8.2 Validation 

8.3 Business Exceptions 

8.4 System Exceptions 


Introduction 
5 

6 

6 
6 
6 
7 

7 

7 
7 
7 
7 

7 

7 
7 
7 
7 

8 

8 
8 
8 
8 

8 

8 
9 
9 
9 

9 

9 
9 
9 
9 

9 


10. 


Security 


Confidential 


©<Company Name>, 2000 


Page 3 


<Project Name> 

Version: <1.0> 

Supplementary Specification 

Date: <dd/mmm/yy> 

<document identified 


Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the Daily Reservation Summary 
screen. 


The system must be able to distinguish, from the physical location of the terminal, the proper screen 
language presentation as well as any field formatting applicable to that particular locale. 


Confidential 


©<Company Name>, 2000 


Page 4 


<Project Name> 

Version: <1.0> 

Supplementary Specification 

Date: <dd/mrnm/yy> 

<document identified 


a 
in 

m 


ru 

IP. 


2. Daily Reservation Summary 


3 Rcscrvolioft Summon/ - Microsoft Internet Explorer provided by Sstcrprbc Rcnt-o -Car 


Detail } Summary * Forecasting 


Notification 


Search 


Reservation Summary for: jjEjBBl ffl 


y (MM/DD/YYYY) 


Group; 


Branch: 


1 01 - St. Louis" 


The First Branch 


Pickup lime 


No Time 


12:00 AM 


12:30 AM 


1:00 AM 


1:30 AM 


frOOAM 


3i00AM: 


3:30 AM 


4:06 AM 


4:30AM 


SsOOAM 


Si30 AM 


fiVAh AM 


No Date 


Reservations 


20 


w/in p/op del ;twc ; uel/r 


Car Class 


Total number of reservations*. 85 


jjS Tkt - 234567 Cbk - 363221 


Figure 1 - Daily Reservation Summary 
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^ f^escE^atwiiSuniinary - Microsoft Internet Explorer provirieAby jnreip riae R en£a-£aE- ____ 


mm 



Detail I Summary ' Forecasting 


Reservation Summary for: B (mm/dd/yyyy) 


Group: 


Branch: 


Pickup Time 



bupMetfc 


Car Class vV|>;^ V ^V.*«: ' - ^ - /' \ . ' ,,' V >* K \ - 

No Time 

5 





i ~1 





12-30 AM 







1:00 AM 








1:30 AM 








2:00 AMf .fF 








2:30 AM 








3ritovAM^:^ 








:.3:30AMtK 
















4:30 AM 








5:00 AMW' 








5:30 AM .-• 








SsOft AM 


1 

\ 




No Date 

20 



I Total number of reservations: 85 


s 



Tkt - 234567 

Cbk - 363221 



Figure 2 - Daily Reservation Summary - Reservation Pilot version 


Group 

3.1 


3.2 


3.3 


Behavior 

This search criterion will be limited to tho*e croups that exist at anv point in time for which the search is 
bein g executed . The selection of "All- is NOT included in the list . This search criteria area will he a d rop- 
down box For Reservati on Pilot the dro p down will only display the user's physical terminal's location 
and the user wi ll not he able to select another group . The users would also like to have the ability to type 
a character, aloha or numeric, into the criteria area and have the drop down list position to the character (If 
the user enters an "H" the drop down list would position to the first string beginning with "H" m the list) 
T I pnn initial pr esentation of the panel this should default to the ptoup associated to the terminal locale. 

Validation 

The items appearin g in the list a re static: the w<" — * *** 1ist dynamically . This should, in 

some manner, he initially defaulted to the terminal's p toup. fbased on physical location) 

Business Exceptions 

None identified at this time. 
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3.4 System Exceptions 

None identified at this time. 

4. Branch 

4.1 Behavior 

This search criterion will be limited to those branches that exist within the ^ roup at anv point in time for 
which the search is being executed . The selection of "All" is NOT included in this selection list. This 
search criteria area will be a drop-down box . The users would also li ke to have the ability to type a 
character, alpha or numeric, into the crite ria area and have the drop down list position to the character. (If 
the user enters an "H" the drop down list would position to the first string beginning with "H" in the list) 
Upon initial presentation of the panel this shou ld default to the branch associated to the terminal locale . 
Branch items appearin g in the list will he limited t o the Group it em selected . Once the selected Group 
item has changed, the branch will be set to blanks . This will require the user to select a branch, at which 
time the display area will be refreshed, renopulated and repositioned. For Reservation Pilot the Branch list 
will NOT contain a blank entry. 

4.2 Validation 

The items appearing in the list are static: the user cannot add items to the list dynamically . This should, in 
iff some manner, be initiall y defaulted to the terminal's branch, fbased on phys ical location! 

Jii This list will be limited to the branches associated with the ^roup selected . 

n 


4.3 Business Exceptions 

m If a user does not enter a branch, or blank s out this area, and attempts to refresh the list, an error message 

f wilLbe_presen ted. See the "error message" supplemental spec for exact text. 

4.4 System Exceptions 

None identified at this time. 

5. Reservation List Pate 

5.1 Behavior 

This area will be a te xt field which will allow the user to ent er the date for which thev want to view 
reservations . The format to enter is mmddw w- * numeric characters, without any delineating characters . 
There will also be a calendar icon func tion which will allow the user to select it and he shown a monthly 
calendar for t hem to select a date . ( As outlined in the HTML standards for Calendar Controls.) 
1 ipon initial presentation of the panel this should default to the current date . 

5.2 Validation 

Validation will occur when the user su bmits the form. It must be a valid month, day and year combination, 

5.3 Business E xceptions 

Tf a user does n ot enter a date, or hlanks out this area, and attempts to refresh the list an error message will 
he present ed. See the " error message" supplemental spec for exact text 

5.4 System Exceptions 

None identified at this time. 
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6. Reservation Display Area 

6.1 Behavior 

The display area will initially be defaulted to all reservation s, for the default group, branch and date. 
The list is positioned to the V 2 hour increment prior to the current time on initial entry, or on refresh, and 
displays the number of reserva tions within l A hour time increments . The scroll bar will be enab led to allow 
the user to view all reservations. 

The result li st will be comprised of 7 static columns, and a text area . The specific column order is: 

1) Time is the first column, formatted bv locale, and shown in V% hour increments . 

2) The number of reservations that have a pick-up time associated with that l A hour increment will be 
displayed next . 

The nex t 5 columns will be the number of times that particul ar pick-up method appears on 
reservations within the "A h our increment . The 5 pick-up methods are: 

3) Walk In . 

4) Pick-Up . 

5) Delivery . 

6) Customer Will Call . 

7) Delivery With Ride Back. 

This is the text area which will contain: 

8) Car Class Summary Area ~ This will d is play all of the car classes on the reservations within that X A 
hour time increme nt and the num ber of times that particular car class appears. 


The sort order of this list is strictly bv the pick-up time and where it falls within the V* hour time increments 
displayed . if there are no reservations for a given 'A time increment t hen the sec ond column will not have 
anv values shown and will be blank.. The list will start at 12:00 A-ML and continue until 1 1 :30 P.M. 
Reservations without a time will appear in a header above the list Reservations without a date and time 
will appear in a footer below the list. 

(These hours may be subject to change in the future, or modifiable, on a case-by-case basis, based on a 
specific branch's hours of operation.) 

The columns within this display list will NOT be sortable . 

The capability also needs to e xist where a user can select a l A hour tim e increment and be taken to, or have 
displayed, the Daily Reservation Detail panel positioned to that selected time increment . 

6.2 Validation 

The user mav not select to edit a reservation that is outside of their security boundaries . 

6.3 Business Exceptions 

Tf a user attempts to edit a reservation that is outside of their security boundaries, an error message of "User 
is not authorized to edit this reservation" should be displayed . 

6.4 System Exceptions 

None identified at this time. 


7. Results Fee dback Line Area 
7.1 Behavior 

This feedback area provides the user with the total nu mber of reservations for the day . If there are 150 
reservations for the selected group, branch and date, with or without pickup time, and 10 without pickup 


Confidential 


©<Company Name>> 2000 


Page8 


<Project Name> 

Version: <1.0> 

Supplementary Specification 

Date: <dd/mmm/yy> 

<document identified 


dates and without pick-times, the total shown would be 160. 

7.2 Validation 

None identified at this time. 

7.3 Business Exceptions 

None identified at this time. 

7.4 System Exceptions 

Button would be enabled appropriately for list display area. 

8. Button Line Area 

8.1 Behavior 

The Refresh image/button will refresh and reponulate the 

The Print List image/button will print the entire list of reservations for the day . 

The New Reserv ation button will create a new reservatio n, changing the screen to that reservation. 

8.2 Validation 

None identified at this time. 

8.3 Business Exceptions a 

None identified at this time. 

8.4 System Exceptions 

None identified at this time. 


9- Rules 

Types of reservations, for the 
he included in the displays are : 

• Voided Reservations . 

• Reservations transferred to another branch . 

• Reservation that have been attached to an open ticket . 

The refresh will be a manual pro cess, no automatic refresh will happen while the user is on this Panel . 

10. Security 

The user must have the appropriate security level to access this screen. The user is allowed to view or print 
anything. It is when they attempt to edit a reservation that their security restrictions will be enforced. 
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<ECARS 2.0 Reservation> 
Use Case Specification: <Edit Branch/ARMS/NATRES 

and Void> 

Version <1.0> 
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Table of Contents 

LI Brief Description 5 

1 .2 The user can enter the reservation for editing from all points of entry into reservation. 

1 .3 The system is able to determine what kind of reservation the user is editing (branch, arms, 
natres, internet) 

1 .4 The system is able to determine whether a reservation is for the group of the physical terminal 
location or from another group. 
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1.5 Update 6 
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L10.4 Rate Plan 
1.10.5 Car Class 
L10.6 Rates 
1.10.7 

1.10.8 CDW 

1.10.9 MI 

1.11 Discounts and Specials 
1111 Add a s pecial 
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If a pickup da te/time already exists in a reservation: 9 


If a return d ate/time alrea dy exists in a reservation: 9 
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Use Case Specification: <Edit Branch/ARMS/NATRES 

and Void> 


Edit Branch/ARMS/NATRES and Void 

1.1 Brief Description 

This use case describes the edit process and field behaviors and dependencies when editing a branch 
reservation, an ARMS reservation and a NATRES reservation. Void rules for reservations are also 
included. 

Pre-Conditions 

1 .2 The user can enter the reservation for editing from all points of entry into reservation. 

1 .3 The system is able to determine what kind of reservation the user is editing (branch, arms, natres, 
internet) 

1 A The system is able to determine whether a reservation is for the group of the physical terminal 
location or from another group. 


Confidential 


©<Company Name>, 2000 


Page 5 


<Project Name> 

Version: <L0> 

Supplementary Specification 

Date: <dd/mmm/yy> 

<document identified 


3 G 

a 

llJ 

nl 
O 

:1 


_!!S» 


Figure 1: Driver Screen: 


:3 Drive? s - Micjosoft Intef net Explorer ptovided by Enterprise Rent a €af . . .. ,* 



______ . ' _ . • • 1 ' 


r 


....... ' - -v^s^fj 


DRIVERS 


James Atteberry 
Additional Drivers; 2 


REFERRAL 


Account Name 
Contact Name 


DATES/RATES 


08/27/2001J ECAR 
Daily Rate; ASD 


BILL-TO 


Account Name 
Contact Name 


VEHICLE/SHOP 


1997 Dodge Avenger 
Shop Account Name 


Notes Taken: 1 
Changed: 


3 


Drivers 

v Atteberry j 
James 


| Smith, 

Cloud, 


f Chris 

Kevin 




Driver 


Other Address 


Insurance Detail 


Cash Qualification 


r Driver Name and Address 

Last Name * First Name 


r Phone Numbers- 
Home 


Work 


Extension 


.j 


Employer 


Other Phone and Type 


-Home Address- 


Address 


{ 

* j 

ZIP 

Country 


| United Stei*j 

City 

State 

t 



-Driver's License 
License Number 

Expiration 
Date 

I - 

State Issued 

(MM/DD/YYYY) 
DOB 

SSN 

(MM/DD/YYYY) 

Height 

I 

Eye Color 
Hair Color 

1 3 

Weight 

Primary Payment Method 


Res - 411781 


Tkt - 234567 


Cbk - 363221 



r t~ "■"•> 


"ZSaJSHsiS _£_____> 


Branch Reservation Edit 

1.5 Update 

• Update button does not show for Edit. 

1.6 Clear 

• Clear button blanks out all driver fields except Country and country issued which are defaulted to the 
country of the terminal's physical location. 

1.7 Driver Fields 

1.7.1 Name: 

a If last name is deleted, the user cannot save the reservation. No edit rules for first name in 
reservation. 

. If the user sel ects Update and the driver's last name and/or first name is changed, no driver 
associated information fields are cleared. 

17.2 Phone Numbers: 

tte eytension will blank out 
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ne is deleted, type will reset to blank. 


• No edit rules for deleting or changing address in reservation. 

1.7.4 Driver's License Fields: 

• If a driver's license number is added t hen the stat e issued, expiration date and DOB fields need 
to be entered as well. 

• If a driver's license number is edited, none of the othe r license fields need to be changed or 
blanked out b y the system. 

• If anv of the four driver's license field s are deleted, the other driver's licens e information that is 
entered remain s, but upon saving the res ervation, the system will alert the user to the missing 
piece(s ) of driver's license information. 

1.7.5 Primary Payment Method: 

• No edit rules exist for changing primary payment method in reservation. 


Figure 2: Referral Screen: 


3|Releirai - Microsoft internet Explorer provided by Enterprise Rent-A-Car 



«1I 



BBfS 


V:SAPPSNEcars w 20\Dev elopment Pjoiect$\HTML\Reserv^on\S^Bf«tat^efr^HrTJ 


Reservation : 411781 


Referral Source 


r Referral — 

<r r Account- 



RENTAL DATES 


Account Name 

[-Select- 

Contact Name 
jj-Select- 


C rEmployee- 


RENTERS VEHICLE 


r Referral Detail 

Bavanan, Inc 

8374 Olive 
Address line 2 

St. Louis, MO 63132 


Account Number 


Account Number: 
Account Type: 

Owning Gp/Br: 
Contact Phone: 


G08799 
Corporate 

0101 

3144691770 


a* 


v 


1.8 Referral Fields 

1.8.1 Account Name: 

• If account name is changed ftp a valid accounts account nnmher will change appropriately and 
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the contact name will now be "select". 

1.8.2 Account Number: 

• If account number is changed, the account name will change appropriately and th e contact name 
will now be "select". 

1.8.3 Employee Number: 

• There are no edit rules for reservation on changing or deleting an employee number. 

1.8.4 Contact Name 

• If contact name is deleted, an error m essage will be displayed to the user to add a contact name 
upon complete reservation. 

1.8.5 If the user decides to remove an account as a referral option, this is the wav the app should 


• If the user blanks out the account name and tabs off or leaves th e field, the Account Number and 
Contact should also be blanked out. 

• If the user blanks out the account number and tabs off or leaves the field, t he Account Name and 
Contact should also be blanked out 


-3 Rates New - Microsoft Internet Explorer provided by Enterprise Rent-a-Par 







$h© ■ ;te & : f , # -a . m - - , 


!^cta|£] Y:\APPS\Ecars_20\DeveJopment Proiects^TML^Rese^ationXRatesV.Retes.html 
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Reservation: 411781 


p Pickup - 
Date: 



Rates/Dates 


Time: 


MM/DD/YYYY HH:MM A 
Method: Location: 



- Return - 
Date: 


Time: 


MM/DD/YYYY HH:MM A 
Method: Location: 

c a t — 


rRate Source" 
Account Name 

HSelect- 

Rate Plan 


-Account Number 


Rental Type 


Car Class 


- Select- 


T 


Rates - 


Car 
Class 


*; Daily:- "V"f4^ Wt»klyi :^ 


jECAR 


15.93 150 59.99 750 


Rats Mileage Rate Charge Charge: 


| _ 173.93 [jigq 1 5. 39 I - oT? r. 


1"' 

V 

>*< 

St 


... . „. . - . B 


Confidential 


©<Company Name>, 2000 


Page 8 


<Project Name> 

Version: <1.0> 

Supplementary Specification 

Date: <dd/mmm/yy> 

<document identified 


1.9 Date Fields 


19.1 Pick up Date: 

If a picku p date/time already exists in a reservation: 

• If the pick up date is deleted, the pi ck u p time is also blanked. 

• If the pick up date is cha nged, the new date follow s the same rules for entering pickup date. 

• If pick up dat e is entered and it is after the return date the user will receive an error message that 
pick up date is aft er the return date and the c orrection must he made bv the user. 

• If the pickup date is in the oast but the field has not been touched during edit, the system will not 
validate the date in this field du ring edit. 

19.2 Pick Up Time: 

• If the pickup time is changed, the new time must me et the same rules for entering pickup time. 

19.3 Pickup Method: 

• If the pick up method is cha nged, the location will remain. 

19.4 Return Date: 

If a return dat e/time already exists in a reservation: 

• If the Return date is deleted, the return time is also blanked. 

. If the return date is chanced, the new d ate follows the same rules for entering return date. 

• If return date is entered and it is before the pick up date the user will receive an error message 
that return date is before the re turn date and the correction must be made bv the user. 

• If the return date is in the past but the field has not be en touched during edit, the system will not 
validate the date in this field during edit. 

• 

19.5 Return Time: 

• If the return ti me is changed the new time must meet th e same rules for entering return time. 

19.6 Return Method: 

. If the return me thod is changed, the location will he blanked out. 


1.10 Rate Fields 

110.1 Account Name 

• If account na me is deleted, the account nu mher and rate plan fields will be blanked. 

• If the account name is changed, the same qi .ideiines for entering an account name apply. Must 
choose from dropdown or from Search. Once a new account name is chosen, the account 
number will populate and if there is only one rate plan for that account that will populate as well 
If there is more than one rate plan to choose from the rate plan field will display "select". 

110.2 Account Number 

• If account n umber is deleted, the accou nt name and rate plan fields will be blanked. 

• If the account number is cha n ged, the sam p guidelines and validations for entering an account 
number ap ply. Once a new a ccount number Is chosen, ths account name will populate and if 
there is onl y one rate plan for that ac count that will populate as well If there is more than one 
rate plan to choo se from the ra te plan field wi» display "select". 

110.3 Rental Type 

• No business rules for editing Rental type apply in reservation. 
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1.10.4 Rate Plan 

• If the user changes the rate plan, "get rates" must be pr essed to retrieve the rates for that rate 


1.10.5 Car Class 

. If car class is changed, "get rates" must be pressed to retrieve rates for the new car class 
entered. 

• If car class is deleted and the get rates button is pressed the table of rates for therate 
source/plan entered will be displa yed. The user has the ability to select a car class from the 
table. 

• If there was no car class originally entered but there were rates entered and the user selects a 
car class, the rate originally entered will remain unless the user manually types over the rates or 
selects a car class from the table of rates after choosing oet rates. 

• Car class may be manually entered with no other rate information. 

1.10.6 Rates 

• Rates Mav be manually entered without a Rate Source. 

• Rates can be deleted. 

• Rates that are edited will rem ain after the rate source is c hanced unless a different car class is 
selected from get rates. 

• Hittin g Cancel after getting rates will keep rates. 


'3 Rates New - Miciosolt Internet EKptorcr provided by Enterprise Rent-a-Car 








I £|d^U51 Y:\APPS\Ecats_20SDeveiopmfint Pro[ects\HTML\Reseivation\R2tes\Rates^_ 

. Mm 





Reservation: 411781 



Rates/Dates 


-Rates , 

[Class 



j^&terv ^ Milearge 

\* Rate \\fctoarge Chargej 

|ecar 

| 15.99' | 150 

| 59.99 j 750 

| 179.95 j 150»3 

| 5.99;| 015 r j 



•ehide Preferences ^ 



L . ..£1*1 _ - 



r Products 

CDW PAI 


•Account Details — 
Hot Une number 1 
Hot Line number 2 


-Discounts and Specials 

r Add A Special _ , % _ _ _ 

r start Bate , t '/^V^Startllme ^ ^ : y; =fewi,pat»;' 'V ^ 1 


,End Time 


id 
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• There are no edit business rules associated with this field in reservation. 

1.10.8 CDW 

• There are no edit business rules associated with this field in reservation. 

1.10.9 EAi 

• There are no edit business rules associated with this field in reservation. 


Figure 5: Rates/Dates Screen (Discounts and Specials): 


'5 Rales New - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 


mum 


e 



|«J Y:\APPS^c*s_20^Deyebpraert 


"3 


Reservation : 411781 



Rates/Dates 


r Account Details - 


Hot Line number 1 
Hot Una number 2 


A 

it 


RATES/DATES 


RENTERS VEHICLE 


-Discounts and Specials- _ __ 

r Add A Special 


MM/DD/YYYY 


HH;MM A 


MM/DD/YYYY 


HH:MM A 




j ] Per Day Special | 

| Per Day jfcj S? 

r Add A Discount 





I 


-I 


1.11 Discounts and Specials 

1.11.1 Add a special 

If add a s pecial is unchecked then sta rt date T start time, end dat e end time, special rate and mileage 
remains but the information is ignore d by the system. 

1.11.2 Start date 

• If start date is changed, the system will validate that the start d ate is not after the end date. 

• If there is a pick up date and the user ch an ges the sp ecial start date to a date before the pick up 
date, the system will inform the user that the start date cannot be before the pick up date. 

• If there is no pick u p date, an d the user ch anges the spec ial start date tn a date before the current 
date, the system will inform the user that the start date cannot be bfrfnre the current date. 
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• If the start date is deleted, the syste m will display a messag e that a start date must b e specified 
for a special 

• If the start date is in the oast but the field h as not been touched during edit, the system will not 
validate the date in this field. 


1,11.3 End date 

• If the end date is changed the system will validate that the end date is not before the start date 
and provide a me ssage if it is. 

• If there is a return date, then the special end date can not be after the return date, otherwise the 
system will displa y a message that the special end date must be eoual to or before the return 
date entered. 

• If the end date is deleted, the system will display a message that an end date must be specified 
for a special. 

• If the end date is in the past but the field has not been touched during edit, the system will not 
validate the date in this field. 


1.11.4 Start Time 

• No business rule for deleting the start time of a special. 

1.11.5 End time 

• No business rule for deleting the end time of a special. 

1.11.6 Rate 

• No business rule for deleting the rate on a special. 

1.11.7 Type 

• There is no validation on changing the type. 

1.11.8 Mileage 

• There is no validation on changing or deleting the mileage for a special. 

1.11.9 Milea ge Type 

• There is no validation on changing the mileage type. 

1.11.10 No charge 

• If there is a mileage charge on the reserva tion there must be a mileage charge for the special, 

• if there is no mileage cha rge on the res ervation there can't be a mileage charge on the special. 

1.11.11 Add a discount 

• If the add a discount box is unchecked when editing , the discount percent remains but is ignored 
by the system. 

• If the discount box is checked when edit ing, a discount must be entered. 

111.12 Discount Percent 

• The discount amount can't be chanced to over 50% or less tha n 1%. otherwise the system will 
inform the user as such. (Discounts must be entered in whole numbersV 
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1.12 Bill-to Screen 

112.1 If the user decides to remove an account as a bill-to accou nt, this is the wav the app 
should behave: 

• If the user blanks out the account name and tabs off or leaves the field the Account Number and 
Contact should also be blanked out. 

• If the user blanks out the account number and ta bs off or l eaves the field, the Account Name and 
Contact should also be blanked out. 

1.13 Shop/Vehicle Screen 

1.13.1 If the user decides to remove an account as a referral, this is the w a y the aoo should 
behave: 

• If the user blanks out the account name and tabs off or leaves the fields the Account Number and 
Contact should also be blanked out 

• If the user blanks out the account number and tabs off or leaves the field, the Account Name and 
Contact should also be blanked out. 


114.1 Protected Fields in ARMS 

• If the reservation originated from the ARMS system there are certain fields ^hat will be 
protected/foot editable bv the userV Thev are as follows: 

1. Claim/PQL/PO Number 

2. Claim Type (C L T) 

3. Insured's Name 

4. Auth Bv 

5. Direct Bill (T.N) 

6. % Auth (not a requirement for Res Pilot) 

7. Max Davs Authorized 

8. Max Billable Amount 

9. Policy Max Amount 

10. Daily Max Amount 

11. Date of Loss 

12. Bill-To Start Date 

13. Bill-To End Date (Auth until Date) 

14. Number of Davs Authorized^? a requireme nt for Res Pilot) 

15. Daily Rate Authorized 

16. Tax Authorized (Y, N) 

17. Car class Authorized 

18. Cancellation Date (Last Dav Date) 

19. Bill-To Account Number (E xce pt if root only is entered then protected once full account 
number is entered) 


1.14.1.1 Editable Fields in ARMS: 

(Note: The following editable fields for ARMS reservations follow the same edit rules as the non-arms 
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Driver Last Name 
Driver First Name 
Hm Phone 
Work Phone 
Extension 
Other Phone 
Phone Description 
Driver's Address 


County 


Other Address 
Employer 
License Number 
Expiration Date 
State Issued 


SSN 


Hair Color 
Eve Color 

1.14.2 ARMS indicator 

ARMs Reservation Modal Dialog Box 


M ARMS Status - Web Page Dialog 


:| 0 


Renter has been contacted, 
(Remove from list) 

Renter has NOT been contacted, 
(Keep on list) 


Note: 
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This modal dialoa box will aoo* 

sar whenever a user chooses to complete an ARMS reservation 


and the status of the rese rvation is either "Not Contacted" or "Contact Attempted 


Upon initial display of the dialoa box, the radio button will default to "Renter has been contacted, 
fRemove from listV. 

If "Renter has been contacted" is selected and the u ser chooses "OK", the system will do the 
following things: 

• The status of reservation will be changed to "Contacted" 

• A note will be added to the Reserv ation notes with the follo wing text. "Renter has been 
contacted." 

• If the user has entered anv text into the "Notes" text area, the entered text will be added 
to the reservation notes as a se cond note. If no text is entered, A note should not be 
generated. 

NOTE: Each of the notes generated will be captured like any other system-generated note 
and given a note type of "Reservation". See the System Generated notes Supplemental 
Spec. 

If "Renter ha s Not been c ontacted is selected and the user chooses "OK", the system will do the 
followin g things: 

• The status of reservation will be changed to "Contact Attempted" 

• A note will be added to the Reservation n otes with the following text. "Attempted to 
contact Renter." , 

• If the user has entered anv text into the "Notes" text area, the entered text will be added 
to the reservation n otes as a second note. If no text is entered, a note should not be 
generated. 

NOTE: Each of the notes generated will be captured like any other system-generated note 
and given a note type of "Reservation". See the System Generated notes Supplemental 
Spec. 

If the user chooses to cancel the system will return the user back to the reservation where the 
user initially selected to complete the reservation. No changes will be made to the reservation 
status and no notes will be generated. If the user tries to complete again, the dialog box will 
display again . 


1.15 NATRES 

1.15.1.1 Protected F ields in Natres 

• A Branch employee cannot edit a National Reservation origina ted reservation. If a 
National Reservation is selected for editing by a branch employee, all fields for the 
Reservation are view only. 

• (See Enhancement #1 080 - Ability to Edit Natres Reservations). 


1.16 Com pleting after Editing information 

• Saving an edited reservation follows t he same business rules as saving a created 
reservation and the same validations occur and informational messages and error 
messages will dis play upon commi tting the edited information to the database. 

1.17 Void 
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1. ARMS? and NATRES res ervations may not be voided by branch personnel. 

2. An outside group cannot void branch reservations for a group other than the owning group of the 
physical terminal signed onto bv the user. 

3. For branch reservations, void must be available to the user on all reservation screens. 

4. The system must confirm to the user that a reservation is being voided. 

5. The void option should only be available once a reservation has been saved and retrieved for edit. 
6. 


Basic Flow: 

1 . User A accesses Reservation 1 23456. 

2. The system opens Reservation 123456 to User A. 

3. The system locks Reservation 123456 for User A immediately. 

a. If User B tries to access Reservation 123456, the use case continues at Alternative Flow 
(Reservation Locked). 

b. If User A's id is used again to access Reservation 123456 on a second terminal, the use case 
continues at Alternative Flow (Stealing Record Lock). 

c. If User A has the Reservation 123456 open more than 30 minutes. 

d. If User B makes updates to Reservation 123456 in Legacy while A has the Reservation open in 
GUI, the use case continues at alternative flow (Legacy to GUI Sync). 

4. If User A completes the reservation in less than 30 minutes and they have continually updated the 
reservation at least every 4 minutes and 59 seconds the system will save the updates and release the logical 
lock on the transaction at the database. 

5. If after 30 minutes, User B accesses Reservation 123456 and. views, edits or saves the reservation, the use 
case continues at Alternative Flow (30 Minute Lock Released). 


Alternative Flows: 

6. Reservation Locked. 

a. User B tries to gain access to Reservation 123456. 

b. The system displays a Lock Warning Screen (File in Use) that informs the user of the following 
information: 

i. A message that the reservation is in use and locked by another employee. 

ii. Employee Number of the person who has the reservation locked for editing. 

///. The user 's Group Branch that has the reservation locked for editing. (For Retrofit) 
iv. The user r s name that has the reservation locked for editing. (For Retrofit) 

c. The User has the option to either Cancel or View Reservation 123456 Read Only. 

i. If User B cancels, the user is returned to where they tried to enter the reservation from 
and the use case ends. 

ii. If User B chooses to Read Only, User B can read the reservation but will not be able to 
edit any of the fields. 

7. Stealing Record Lock 

a. User A's id is used again to access Reservation 123456 on a second terminal. 

b. Both terminals have simultaneous lock on the reservation. 

c. Whichever terminal saves first wins and releases the record lock. 

d. For retrofit, User A will not be able to steal record lock from self 

8. 30 Minute Lock Released 

a. After 30 minutes, the system releases the record lock 

b. User B accesses Reservation 123456 

c. User B updates Reservation 1 23456. 
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d. The system saves Reservation with User B 's updates. 

e. When User A tries to save Reservation 123456 after User B has already saved it, the system will 
display a message that the reservation has been updated and ask if they would like to view the 
updated version. 


8.5 30-Minute Lock Released but Not Accessed by User B. 

a. After 30 minutes, the system releases the record lock. 

b. No other users access Reservation 123456. 

c. User A attempts to save Reservation 123456. 

d. System locates User A*s dormant ID as last locked ID. 

e. System saves Reservation 123456 to User A. 

9 . Legacy to GUI Sync. 

a. During the time User A has Reservation 123456 open in GUI, User B accesses Reservation 
123456 in Legacy. (User B, in Legacy, is not locked out) 

b. User B updates and saves to reservation 123456. 

c. System initiates sync between GUI and Legacy. 

d. Record updated in Oracle. 

e. Lock is released 

f. User A attempts to complete Reservation 123456 and the system will display a message that the 
reservation has been updated and ask if they would like to view the updated version. 

# 

Note: One Record Lock message needed for pilot. Additional Record Lock messages will be used in Retrofit. 


Special E dit Rules 

1. The followin g rules apply for the editing of all date fields: 

When editing a reservation if the date fnr any date field is not added, deleted or changed the 


field is not validated bv t he system. 


If a date in a date field is changed, added or deleted then the system will validate those fields 
u pon leaving the screen in the same w ay as validated when creating a reservation. 
These rules appl y to all d ate fields in reservation. 

2. When a user opens a NatRes voided or closed reservation, or a reservation attached to 
a ticket, a popup window will appear immediately after the reservation is opened. The 
message will tell th e user that c hanges made to this reservation cannot be saved. The 
Complete button will be disabled on all screens The Complete option will be removed 
from the menu bar for this transaction. The Tran sfer and Void options will be removed 
from the title bar option control. 
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3. 3. Voided re servations, reservations attached to open tickets and closed reservations 
(reservations attach ed to closed t ickets) cannot be searched for and do not appear on the 
Reservation Summary screens. T hese reservation mav only be viewe d bv entering the 
reservgtion number in Reservation Fast Path. 

Post-Conditions 

1.19 < Post-condition One > 

Extension Points 

1.20 <Name of Extension Point> 
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Supplemental Specification 

1. Hot Kevs 

The purpose of this document is to identify every hot key within each screen of a Reservation 
1.1 US English S creens 

1.1,1 Detail Screen 

The reservation detail screen is used to determine what reservations will be coming in for a specific day. 
The user will refresh this list frequently to keep it updated. 


'2 Reservation Detail - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 


Detail [ Summary | Forecasting 
Group: 


1 01 - St. Louis 


Branch: 
B iThe Rrs1 Branch" 


Edit Reservation Number: 


Washington, George 



5/9 


DEL 


Front step of City Hall. LCAR 


Corporate 


5/9 9i3DAM Attebemi, James 


W/IN 


SCAROOl 


Reta, 


1 


5/9 8:45 AM SnuffiteHi, Joe 


P/UP 


Home 


Something with 4 wheels 
ECAR and an engine that won't Insurance 

leak oil. 


5/9 8:45 AM Zukow, Thomas 


DEL/R 


Service garage for Lou 
Fuss Dodge 


Dodge Viper with tow 
package installed 


Dealership 


5/9 10:30 AM Antilles, Wedge 


W/IN 


XCAR 


Corporate 



5/9 12:00 PM Solo. Hans 


XCAR 


Anything that can make 
theKesselRun Retail 


5/9 12:15 PM Graves, Paul 


CWC 


ICAR 


V6 engine 


Insurance 


5/9 1 1 20 PM Jones. Christopher 


P/UP 


County Jail 


No bars in windows 


Government y? 


5/9 


1:20 PM Smith, Chris 


W/IN 


CCAR 


Retail 


NoOate, NoTims 


W/IN 


Retail 


fotal number of reservations: 10 


Tkt-Z34S67 Cbk - 363221 


0 

: 1 

;; 

A 

VI 


The Hot Kevs that apply to this screen are: 


Text Label 

North America 

Germany 

Purpose of button 

Refresh 

E 

K 

Re-submits the page to get the most 
current data 

Print list 

P 

D 

Prints all the records in the summary list 

Edit 


B 

Is in regard to changing an existing 
reservation 

Detail 

D 

A 

Navigates the user to the Reservation 
Detail Screen 

Summary 

y 

Z 

Navigates the user to the Reservation 
Summary Screen 
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Forecastina 

Q 

o 

Navigates me user to trie Reservation 
Forecasting screen 



N 


Search 

§ 

s 

Navigates the user to the Reservation 

New Reservation 


u 

This button is used when a user wants to 
create a new reservation for a potential 
customer. 

Transaction 1 

1 

1 

Navigates the user to the first open 
transaction 


2 

2 

Navigates the user to the second open 
transaction 

Transaction 3 

3 

3 

Navigates the user to the third open 
transaction 1 
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112 Summary S creen 

The Reservation summary screen is used to determine how many reservations are coming into the 
branch during a specific Vz hour period for a specific day. 


3 KcservirHon: Summary - Microsoft In+ernc+ Hxptorcr provided hf Enterprise ftcnf-a-Car. . f 


Reservation Summary for: ESsBBl B qin/do/yyyy) ^ 


Group: 


Detail | Summary , Forecasting Notification [ Search 


Branch: 


01-St Louis 


The First Branch 


No Time 


12im AM: 


V2:3d : «W'-',--'; 


3;0O AM 


4:30 AM 


No Date 


20 



Car Ctass 


- <l 


■ -i 


Total number of reservations: 85 


Res - 4117*1 


Tkt - 234567 | Cbk - 363221 


The Hot Kev s that apply to this screen are 


Text Label 

North America 

Germany 

Purpose of button j 



K 

Re-submits the page to get the most current 
data 

Print Summary 

E 

D 

Prints the entire day of Vz hour intervals 
because all the % hour intervals may not be 
visible on the screen 

Detail 

D 

A 

Navigates the user to the Reservation Detail 
Screen 

Summary 

U 

Z 

Navigates the user to the Reservation 
Summary Screen 

Forecasted 

Q 

0 

Navigates the user to the Reservation 
Forecasting screen 



N 


Search 

s 

S 

Navigates the user to the Reservation 
Search Screen 

New Reservation 

W 

U 

This button is used when a user wants to 
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ureal© a new reservation tut a putenuai 
customer. 

Transaction 1 

1 

1 

Navigates the user to the first open 
transaction 

Transaction 2 

2 

2 

Navigates the user to the second open 
transaction 


a 

3 

Navigates the user to the third open 
transaction 
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113 Forecasting Screen 

The Reservation forecasting screen is used to determine how many reservations are booked for a 
particular day within a 14-day period. 


I^RescrvoHon forecasting - Microsoft; Internet Explorer provided by Enterprise ftenf-a-Cor 


pel 




i - 

\ \ Detail 

Summary | Forecasting : Notification Search 

, 4 

I Reservation Forecasting Starting on: H cmm/po/wyy) 


[ Group: Branch: 


. 1 

1 1 01 - St. Louis H l The Rrst Branch S 


May 25, 2001 through June 7, 2001 

Previous 14 Davs Next,.14 D_a Y .s. 

J 

:J 
Mi 

vj 
..:| 

>! 







Thursday 

j May 25 

May 26 

May 27 

May 28 

May 29 

May 30 

May 31 

12 

5 


25 

2Z 

IS 

15 

June 1 

June 2 

June 3 

June 4 

JuneS 

June 6 

June 7 

13 

4 


22 

IS ! 

1Z 



■J 


Tkt - 234567 Cbk - 363221 




The Hot Kevs that are available to the user are: 


Text label 

North America 

Germany 

Purpose of button 

R.eftasii 

E 

K 

Re-submits the page to get the most current 
data 

Detail 

O 

A 

Navigates the user to the Reservation Detail 
Screen 

Summary 

u 

Z 

Navigates the user to the Reservation 
Summary Screen 


S 

o 

Navigates the user to the Reservation 
Forecasting screen 



N 


Search 

i 

S 

Navigates the user to the Reservation Search 
Screen 

New Reservation 

m 

U 

This button is used when a user wants to 
create a new reservation for a potential 
customer. 

Transaction 1 

1 

1 

Navigates the user to the first open 
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transaction 

Transaction 2 

2 

2 

Navigates the user to the second open 
transaction 

Transaction 3 

2 

3 

Navigates the user to the third open 
transaction 



114 Notification Screen 

The Reservation Notification screen is used to show the user the reservations that need to be confirmed 
immediately. 


i-gj ARMS Ihdrcotat* V2 - Microsoft" Internet Explorer provided hy Enterprise Rent-a-Car 



Retail [ Summary j Farecasting | Notification j Search | 


Reservation Notification 


s S 

is 


InJ 

ii 






Reservation 

Reservation 

< 

r \ 

11 1 

;: 




Created 

Created 

* ^.Number . 

•ft t 

Z — i 


\ 

, 

04/03/01 

8:30 AM 

Atteberrv, James 

Honest Bob's Collision Repair and 
Gun Store 

02/20/01 

11:35 AM 

123456 



1 

04/10/01 

8:30 AM 

Snuffitelli. Joe 

Firestone 

02/27/01 

2:31 PM 

234567 



( 
j 

04/10/01 

9:45 AM 

Smart. Maxwell 

Classified 

03/05/01 

7:30 AM 

34S67S 

f 

hi 

1 




Carl's Auto 

04/29/01 

3:15 PM 

BG43W2 


04/01/01 

6i45 AM 

Doe, Jane 

Fleecem Insurance 

04/01/01 

S:40 AM 

456783 


Si 

1 

04/02/01 


Veaoer, Chuck 

USAF 

04/02/01 

1j23 PM 

MACHO 1 

- [ 



j 04/02/01 

1;45PM 

j-obqehevsh, Steven 

No Problem Coverage 

04/02/01 

12:00 PM 

S67890 




I 04/03/01 

2:30 PM 

Alien, Roqsr 

Pooh Insurance 

04/03/01 

1 li 30 AM 

D54Q87 


ru 







































M 


















i 


T, 


otal number of reservations: 10 


Reservations in Bold are a priority. 



Tkt - 234567 


Cbk - 363221 


<1 


'J 


4 


The hot ke ys that are av ailable to the user are: 


Text label 

North America 

Germany 

Purpose of button 

Refresh 

£ 

K 

Re-submits the page to get the most 
current data 

Detail 1 


A 

Navigates the user to the Reservation 
Detail Screen 

Summarv 

y 

Z 

Navigates the user to the Reservation 
Summary Screen 

Forecastina 

a 

0 

Navigates the user to the Reservation 
Forecasting screen 



N 
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Search 

§ 

S 

Navigates the user to the Reservation 

New Reservation 

m 

u 

This button is used when a user wants 
to create a new reservation for a 
potential customer. 

Transaction 1 

1 

1 

Navigates the user to the first open 
transaction 

Transaction 2 

2 

2 

Navigates the user to the second open 
transaction 

Transaction 3 

a 

3 

Navigates the user to the third open 
transaction 


1.1.5 Search Screen 

The search screen allows the user to locate a specific reservation by entering specific criteria. 


W 

hi 

I W 

m 



Retail [ Summary J forecasting \ MotificatiorT | Search ) 


Reservation Search 


Group; 


Branch: 


01 -St. Louis 


The First Branch 


Renter Last Name 


Renter First Name: 


Renter Telephone Number; 


Advanced Search 

Reservation Number: 



Items 1 - 10 of 50 found 


Prev 12 3 4 5 Next 



Tkt - 234S67 Cbk - 363221 


ThA Hot Kevs that are avai lable to the user are: 


4« 


I Text label 

North America 

Germany 

Purpose of Button 

Reset 

_E 

0 

Clears the data out of all the fields 

Print Current 

1 

T 

Since a search can return more than 1 page of 
results, this will print only the current page that 
is displayed to the user 

Page 




Confidential 


©<Company Name>, 2000 


Page 10 


<Project Name> 

Version: <1.1> 

Supplementary Specification 

Date: <dd/mmm/yy> 

<document identified 


Print List 

£ 

D 

Prints all the records found regardless of the 
numoer ot pages 

Detail 

St 

A 

Navigates the user to the Reservation Detail 

Summary 

u 

Z 

Navigates the user to the Reservation Summary 
ocroen 

ro recast! no 

y 


j\avigaies tne user to ine r\cservauon 
Forecasting screen 



M 

IN 


Search 

s 

s 

Navigates the user to the Reservation Search 
Screen 

New Reservation 

m 

U 

This button is used when a user wants to create 
a new reservation for a potential customer. 

Transaction 1 

1 

1 

Navigates the user to the first open transaction 

Transaction 2 


2 

Navigates the user to the second open 
transaction 

Transaction 3 

2 

3 

Navigates the user to the third open transaction 


116 Driver Search Screen 

This screen is used to find a repeat renter's information to add to a reservation transaction. The user 
searches by the criteria listed and will pick one of the repeat renters returned from the search. If the user 
does not find the renter they are looking for, they will use the New Driver button to&tart a reservation 
without any renter information pre-filled. 
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3E384GG 0101 Enterprise* ECARS Applicati on - Microsoft Internet Explorer Provided by Enterprise Rent-a-Car 


Driver Search 


Phone Number Last Name: First Name 


SEES! 


DRIVERS 


|j Additional Drivers; 1 


REFERRAL 


License Number: 


Date of Birth: 







is 


1 BILL-TO 


VEHICLE/SHOP 


I Notes Taken : 2 


The Hot kevs available to the user are : 


Text label 
Reset 

Referral 

North America „ 

E 

D 

R 

I 

Germany 
0 

_A 

W 
P 

Purpose of Button 

Clears the data out of all the fields - 

Navigates the user to the Driver screen 

Naviqates the user to the Referral screen 

Navigates the user to the Dates/Rates 

screen 

Naviqates the user to the Bill-to screen 

Bill-to 

Vfihicle/ShoD 

B 

H 

R 
F 

Navigates the user to the Vehicle/Shop 
screen 

Navigates the user to the Notes screen 

Notes 
New Driver 

_Q . , 

m 

_0 

U 

Navigates the user to the Drivers screen 
with no renter data populated 

Transaction 1 

1 

1 

Navigates the user to the first open 
transaction 

Transaction 2 

2 

2 

Navigates the user to the second open 
transaction 

Transaction 3 

2 

3 

Navigates the user to the third open 
transaction 
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1.1.7 Driver Screen 

This screen is used to fill in all the data about a renter. The user can enter more than one renter. When 
the user needs to add an additional driver to a reservation, they will use the "Add'l drivers" button to 
create another instance of the driver screens. 



Account Name 
j Contact Name 


DATES/RATES 


08/27/2001; ECAR 
Daily Rate; ASD 


DRIVERS 


James Atteberry 
Additional Drivers: 2 


REFERRAL 


BILL-TO 


Account Name 
Contact Name 


VEHICLE/SHOP 


1997 Dodge Avenger 
Shop Account Name 


Notes Taken; I 
Changed: 08/27/2001 


\ 


Atteberry, : | 

Smith, 

Cloud, 

3ames ; 1 

Chris 

Kevin f 



Driver : 


Other Address 


Insurance Detail 


Cash Qualification 


rDriver Name and Address- 


Last Name * 


First Name 

ir — 


r Phone Numbers - 
Home 


Work 


Extension 


Employer 


Other Phone and Type 


-Home Address - 
Address 



Res - 411781 


Tkt - 234567 Cbk - 363221 


r Driver's License 

Expiration 
License Number Date 


i 1 ! 


CMM/DD/YYYY) 

State Issued 

DOB 



CMM/DD/YYYY) 

SSN 

Height 


Eye Color 


Weight 

CZ3 


Hair Color 


Primary Payment Method 


The Hot Key 


to the user are: 


Text label 

North America 

Germany Purpose of Button 

Add'l Drivers 

A 

E 

Used to add more than one driver to a 
reservation 

Update 

y 

A 

if the user has to update a Repeat 
renter's data. 

Clear 

L 

L 

Used to clear ail the driver data fields at 
once. 

Drivers 

D 

A 

Naviaates the user to the Driver screen 

Referral 

R 

W 

Navigates the user to the Referral 
screen 

Dates/Rates 

I 

P 

Navigates the user to the Dates/Rates 
screen 

Bill-to 

B 

R 

Navigates the user to the Bill-to screen 

Vehicle/Shoo 

a 

F 

Navigates the user to the Vehicle/Shop 
screen 
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Notes 


O 


Navigates the user to the Notes screen 
Navigates the user to the next main 
area within the transaction navigation 
bar 


Complete 


B 


G 


Saves the transaction 

This is used to exit the transaction that 
the user is working on. No data will be 
saved from the point when the user last 
saved. 


Driver 


Other Address 


nash Qualification 


Insurance Detail 


Transaction 1 


Q 


H 


U 


Navigates the user to the Driver screen 
when the user might be working on 
more than one driver 


Navigates the user to the Other 
Address screen for the current driver (if 
more than one) 


Navigates the user to the cash 
qualification screen for the current 
driver (if more than one) 
Navigates the user to the Insurance 
Detail screen for the current driver (if 

more than one) 

Navigate%the user to the first open 
transaction 



Navigates the user to the second open 
transaction 

Navigates the user to the third open 
transaction 
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3 « 5 

Sj 

1SSW 


118 Other Address. Cash Qualification. Insurance Detail Sub-Screens 

These screens are used to capture additional data about a Driver The other address allows the user to 
enter a second address for a renter. The cash qualification screen provides additional data areas to 
underwrite a driver that may not have a credit card. The insurance detail screen provides an area for the 
user to capture the details of the Drivers Personal Car Insurance. 



ThP Hot Key* available to thft user on e°<** of jfag ih-srraens are: 


Purpose of Button 

Navigates the user to the Driver screen 
Navigates the user to the Referral screen 
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Exit "X" 


X 

This is used to exit the transaction that the 
user is working on. No data will be saved 
from the point when the user last saved. 

Driver 

I 

H 

Navigates the user to the Driver screen when 
the user might be working on more than one 
driver 

Other Address 

g 

A 

Navigates the user to the Other Address 
screen for the current driver (if more than 
one) 

Cash Qualification 

Q 

0 

Navigates the user to the cash qualification 
screen for the current driver (if more than 
one) 

insurance Detail 

§ 

s 

Navigates the user to the Insurance Detail 
screen for the current dnver (if more than 
one) 

Transaction 1 

1 

1 

Navigates the user to the first open 
transaction 

Transaction 2 

2 

2 

Navigates the user to the second open 
transaction 

Transactions 

2 

3 

Navigates the user to the third open 
transaction 


* 

1.1.9 Referral Screen 

This screen is used to capture the data of who referred the renter to Enterprise. This can be either an 
Enterprise Account or Enterprise Employee. 
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i 


| 08/27/2001; ECAR 
Daily Rate; ASD 

Account Name 
Contact Name 


James Atteberry 
Additional Drivers: 2 


REFERRAL 


Account Name 
Contact Name 


r Referral 


I 1997 Dodge Avenger 

1 ES 

Shop Account Name 


Notes Taken: 1 


Changed; 
08/27/2001 


r Account 


Account Name 
[-Select- 


Contact Name 


O rEmployee- 


r Referral Detail 

Bavarian, Inc 
8374 Olive 
Address line 2 
St. Louis, MO 63132 


Account Number 



Contact Phone Ext 

C=3 


Account Number: 
Account Type: 

Owning Gp/Br: 


G08799 
Corporate 

0101 


: ,1 


■ J 


•3 


vl 


v '1 


Tkt - 234567 Cbk - 363221 


The Hot Kevs available to the user are: 


Text label 

North America 

Germany 

Purpose of Button 

Search 

i 

S 

Navigates the user to the account or 
employee search screen 

Drivers 

D 

A 

Navigates the user to the Driver 
screen 

Referral 

B 

W 

Navigates the user to the Referral 
screen 

Dates/Rates 

I 

P 

Navigates the user to the Dates/Rates 
screen 

Bill-to 

§ 

R 

Navigates the user to the Bill-to 
screen 

Vehicle/ShoD 

H 

F 

Navigates the user to the 
Vehicie/Shop screen 

Notes 

Q 

O 

Navigates the user to the Notes 
screen 

Previous 

v 

V 

Navigates the user to the previous 
main area within the transaction 
navigation bar 

Next 


N 

Navigates the user to the next main 
area within the transaction navigation 
bar 
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Complete 

C 

G 

Saves the transaction 

Exit "X" 

X 

X 

This is used to exit the transaction 
that the user is working on. No data 
will be saved from the point when the 
user last saved. 

Transaction 1 

1 

1 

Navigates the user to the first open 
transaction 

Transaction 2 

2 

2 

Navigates the user to the second 
open transaction 

Transaction 3 

2 

3 

Navigates the user to the third open 
transaction 
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1.1.10 Dates/Rate s Screen 

This screen is used to capture all the particulars of a reservation. This includes Pick-up date, Return 
Date and allows the user to search for a rental rate for the reservation. This screen handles any 
additional product or fees that are associated to the rate or pick-up location. 


The screen shot is broken into two shots because of the screen s crolls vertically. 


'3 Rates New - Microsoff Io1crnc+ Explorer provided by Enterprise Rcn+-<x-Car 



DRIVERS 


Driver summary 1 
Driver summary 2 


REFERRAL 


Referral sum l 
Referral sum 2 


Dates summary 1 
Dates summary 2 

Bill-To summary 1 
Bill-To summary 2 


i 


Vehicle/Shop 1 
Vehicle/Shop 2 

Notes summary 1 
Notes summary 2 


Rates/Dates 


-Pickup' 
Date: 


Time: 


- Return- 
Date ; 


Time: 


MM/DD/YYYY 
Method: 


HH:MM A 
Location: 


MM/DD/YYYY HH: MM A 
Method: Location: 


rRate Source— 
Account Name 

FggjggH 


Account Number 


Rental Type 


Rate P(an 


Car Class 


- Select - 


r Rates - 


15.93| | 150| | 59.99{ I 750j | T^lSf I 1500! \ 5i 


Charge Charge 


D 




i 


s V 


Tkt - 23*1567 Cbk - 36322J 
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[ 


DRIVERS 


Driver summary 1 
Driver summary 2 


REFERRAL 


Referral sum 1 
Referral sum 2 


DATES /RATES 


Dates summary 1 
Dates summary 2 


BILL-TO 


Bill-To summary 1 
Bill-To summary 2 


VEHICLE/SHOP 


r Account Details — 
Hot Line number l 
Hot Line number 2 


I Vehicle/Shop 1 
Vehicle/Shop 2 


Notes summary 1 
Notes summary 2 



Rates /Dates 


MM/DDAYYY 


HH:MM A 


MM/DD/YYYY 




| Per Day Special 

■ 1 1 1 ! o 


D Add A Discount 

I \% 


- Options -1 


f Discounts and Specials — ' — - 

151 Add A Special 



Res - 411781 


iTkt-234567 Cbk - 363221 


The hot kevs available to the user are: 


Text label 

North America 

Germany 

Purpose of Button 

Search 


S 

Navigates the user to the Account search 
screen 

Directions 


B 

Allows the user to enter directions to the 
pick-up location 


Get Rates 

fi 

Z 

Tells the system to go took for any rental 
car rates that are set up for the Account 
chosen as the rate source. 


VLE 

L 

1 

Displays the table of Vehicle License 
fees. VLF is a tax that is applied to 
rentals in the states of California and 
Hawaii only. 

More 

M 

M 

Navigates the user to a screen that 
displays all the rate source account's 
information. 

Drivers 

D 

A 

Navigates the user to the Driver screen 


B 

W 

Navigates the user to the Referral screen 

Dates/Bales 

I 

P 

Navigates the user to the Dates/Rates 
screen 

Bill-to 

B 

R 

Navigates the user to the Bill-to screen 
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Vehicle/Shop 

H 

F 

Navigates the user to the Vehicle/Shop 
screen 

Notes 

Q 

0 

Navigates the user to the Notes screen 



V 

Navigates the user to the previous main 
area within the transaction navigation bar 

Next 

K 

N 

Navigates the user to the next main area 
within the transaction navigation bar 

Complete 

Q 

G 

Saves the transaction 

Exit "X" 

X 

X 

This is used to exit the transaction that 
the user is working on. No data will be 
saved from the point when the user last 
saved. 


Transaction 1 

1 

1 

Navigates the user to the first open 
transaction 

Transaction 2 

2 

2 

Navigates the user to the second open 
transaction 

Transaction 3 

2 

3 

Navigates the user to the third open 
transaction 
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1.1.11 Bill-to Screen 

This screen is used to capture the information about an account that is authorizing Enterprise to bill them 
for some portion or the entire rental. 



The hot keys available to the user are: 


Text label 

North America 

Germany 

Purpose of Button 

Search 

§ 

S 

Navigates the user to the Account 
Search screen 

Not On File 

E 

D 

Allows the user to create a new bill-to 
account if the account cannot be 
located in the account database. 

RateJist 

L 

L 

Shows the rates of the account that is 
selected as the Bill-to 

Drivers 

P 

A 

Naviqates the user to the Driver screen 

Referral 


W 

Navigates the user to the Referral 
screen 

Dates/Rates 

T 

P 

Navigates the user to the Dates/Rates 
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screen 

Bill-to 

fi 

R 

Navigates the user to the Bill-to screen 

Vehicle/Shop 

M 

F 

Navigates the user to the Vehicle/Shop 
screen 

Notes 

Q 

O 

Navigates the user to the Notes screen 

Previous 


V 

Navigates the user to the previous 
main area within the transaction 
navigation bar 

Next 


N 

Navigates the user to the next main 
area within the transaction navigation 
bar 

ComDlete 

c 

G 

Saves the transaction 

Exif'X" 


X 

This is used to exit the transaction that 
the user is working on. No data will be 
saved from the point when the user 
last saved. 

Transaction 1 

l 

1 

Navigates the user to the first open 
transaction 

Transaction 2 

2 

2 

Navigates the user to the second open 
transaction 

Transaction 3 

2 

3 

Navigates the user to the third open 
transaction 
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1.1.12 Vehicle/Shop Screen 

This screen is used to capture data about the Renter personal vehicle and data about the shop that will 
be fixing it 


y 5 Renter *s Vehicle / Shop - Microsoft In+crnct Expforcr: provided hy Enterprise ftcnt-a-Car 




f Driver summary 1 
Driver summary 2 


REFERRAL 


I 


Referral sum 1 
Referral sum 2 


DATES/RATES 


Dates summary 1 
[ Dates summary 2 


BILL-TO 


Bill-To summary 1 
Bill-To summary 2 


VEHICLE/SHOP 


Vehicle/Shop 1 
Vehicle/Shop 2 

Notes summary 1 
Notes summary 2 


r Vehicle - 
Year 


Make 


Other Make 



Model 

Other Model 


i 

ir i 

i 

Color 

Other Color 




rLoss Information - 
Is Car 
Driveable? 


Type 
of Loss 


Total Loss? 


Date of Loss 


mm/dd/yyyy 


Theft Waiver Days 


Vehicle Notes 


Shop 


pShop 

Account Name 

[-Select- ~~ 


Account Number 


Contact Name 
[-Select- 


Phone Number 


ii 


:1 


> 3 

31 



The hotkeys 


Text label 

North America 

Germany 

Purpose of Button 

Search 


S 

Navigates the user to the Account Search 
screen 

Not On File 

E 

D 

Allows the user to create a new bill-to 
account if the account cannot be located in 
the account database. 

Drivers 

D 

A 

Navigates the user to the Driver screen 

Referral 

R 

W 1 

Navigates the user to the Referral screen 

Dates/Rates 

I 

P 

Navigates the user to the Dates/Rates 
screen 

Bill-to 

B 

R 

Naviqates the user to the Bill-to screen 

Vehicle/ShOD 

a 

F 

Navigates the user to the Vehicle/Shop 
screen 

Notes 

0 

0 

Navigates the user to the Notes screen 

Previous 

v 

V 

Navigates the user to the previous main 
area within the transaction navigation bar 
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Next 

a 

N 

Navigates the user to the next main area 
wiinin tne transacxion navigation oar 

Complete 

c 

G 

Saves the transaction 

CaII a 

Y 

A 

Till© fe ncaH f*^ /a vif frone^a/^ti^n tK'Qt fHa 

i nis is useu to exii ine transaction inai me 
user is working on. No data will be saved 
from the point when the user last saved, 

Transaction 1 

i 

1 

Navigates the user to the first open 
transaction 

Transaction 2 

2 

2 

Navigates the user to the second open 
transaction 


2 

3 

Navigates the user to the third open 
transaction 
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1.1.13 Notes 

This screen is used to log any miscellaneous information about a reservation that isn't captured on the 
other screens. 



Referral sum 1 
Referral sum 2 


DATES/RATES 


Dates summary 1 
Dates summary 2 


BILL-TO 


Bill-To summary 1 
Bill-To summary 2 


VEHICLE/SHOP 


Vehicle/Shop 1 
Vehicie/Snop 2 


NOTES 


Notes summary 1 
Notes summary 2 


07/03/2001 Car is at Joe's . Garage 
3522PM ~" 


07/02/2001 Does not like red cars. Th is sho*s the first two 
. 2i22PM lines of the notes seetior..(2 45 char).., 


Open 


System 


System 


Sent 


07/01/2001 Reservation Created 
1:22PM 


Reservation System 


System 


Sent 


> 1 


4 


4 


I 


Res - 4117&1 


Tkt - 234567 Cbk - 363221 


The hot kevs available to the 


Text label 

North America 

Germany 

Purpose of Button 

Pcm\ All Records 

E 

D 

Prints all notes that have been saved 
regardless of what is displayed on the 
screen 

Add Note 

A 

Z 

Allow the user to enter a text note. 


D 

A 

Navigates the user to the Driver 
screen 

Referral 

R 

W 

Navigates the user to the Referral 
screen 

Dates/Rates 

I 

P 

Navigates the user to the Dates/Rates 
screen 

Bill-to 


R 

Navigates the user to the Bill-to 
screen 

Vehicl.e/Sh_o_p_ 

M 

F 

Navigates the user to the 
Vehicle/Shop screen 

Notes 

0 

0 

Navigates the user to the Notes 
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screen 

Previous 

V 

V 

Navigates the user to the previous 
main area within the transaction 
navigation bar 

Next 

M 

N 

Navigates the user to the next main 
area within the transaction navigation 
bar 

Complete 

Q 

G 

Saves the transaction 

Exit "X" 


X 

This is used to exit the transaction 
that the user is working on. No data 
will be saved from the point when the 
user last saved. 

Transaction 1 

1 

1 

Navigates the user to the first open 
transaction 

Transaction 2 


2 

Navigates the user to the second 
open transaction 

Transaction 3 

3 

3 

Navigates the user to the third open 
transaction 
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1.1.14 Account/Employee Searqh 

This screen is used when a specific account or employee needs to be located and used as a Referral, 
Bill-to, Rate Source or Shop. 



i 


i 


A Collector's Bookstore** 


<3E1658 Corporate 0101 6275 Delmar 


St. Louis MO 63130 (314)721- 
6127 


A.f.i. Remodeling Co* 


GE1225 Corporate 0102 312 Oak Pk. Village Dr. 


Wildwood MO 63040 (636)458- p 
1552 <M 


Accent Uncoln-mcrcury** 


129493 Dealership 0103 9700 Manchester Rd 


St Louis MO 631 19 (314)963- -rj 
5300 'Xl 


Advantage Decorating** 


•3E0853 Corporate 0104 1601 North 7th St. 


African Aroer. Rrte Of Passage* 


<3E1538 Corporate 0105 325 Debaliviere 


St. Louis MO 63102 (314)436- VI 

£12 3 

St. Louis MO 63112 (314)3J61- $,\ 


2268 


Ahzad feogosian* 


GEQ830 Corporate 0106 7743 Arthur 


St, Louis MO 63U7 (314)645- 
3076 


Aig-cs** 


GE0238 Corporate 0107 120 S Centra), Ste 300 


St Louis MO 63105 (000)000- *£| 
OOOQ 


^<SEJL35,CLwP>XBorar e , 185 S& . 0M,H v >ul66^ 


„JUcrfk MO 63XL63~^X636X27X^ 


Items l - 66 of 66 found 


Prev 12 3 4 5 Next 


X 


.v>| 


Tkt - 234567 Cbk - 363221 


- J 


The hot k evs available to the user are: 


Text label 

North America 

Germany 

Purpose of Button 

Reset 

E 

0 

Clears the data out of all the fields 

Cancel 

A 

A 

Returns the user to the screen where the 
user initiated the search 

Transaction 1 

1 

1 

Navigates the user to the first open 
transaction 

Transaction 2 

2 

2 

Navigates the user to the second open 
transaction 


2 

3 

Navigates the user to the third open 
transaction 
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8/22/0 i 

1.0 

First Draft 

Mike Pallia 

8/24/01 

1.1 

Changes made after user review 

Mike Pallia 

8/27/01 

1.2 

More Changes from the User Review. This 
is the final version. 

Mike Pallia 
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Supplemental Specification 

1. Navigation and Scre en Layout 

The screens within the Transaction Sub-application of ECARS 2.0 were broken down into specific areas. Each area 
has a specific purpose and should be implemented as such throughout the rest of ECARS 2.0 to give the users a 
consistent look and feel for every part of the sub-application. This includes Hot Keys, Tabbing and Navigation 
areas within a Summary, Transaction or Search screen. 

1.1 Summary Screen Layout 

These are the standards for the Summary screens. A Summary screen is often the home page for a particular sub- 
application. It allows the user to quickly gain useful information about that sub-application. Summary screens can 
be several screens linked together. 


3 Reservation Detail - Microsoft Internet Explorer provided hy Enterprise Rent-a-Car 


Summary 


Forecasting 


Notification 


Summary Navigation Bar 


Reservation List for: TSSSMt H (mm 


MM/OD/VYVV) 


Edit Reservation Number: 


Group; 


01 - St. Louis 


Branch: 

| The First Branch 


[ 


lipy 


Km 













3/9 

WasMnoton, Seorae 

DEL 

Front step of City Hail, 

LCAR 


Corporate 


5/9 

8:30 AM Atteberry.. James 

W/IN 


SCAR0G1-- 


Retail 


5/9 

8:45 AM Snuflfitelli, Joe 

P/UP 

Home 

ECAR 

Something with 4 wheels 
and an engine that won't 
leak oil. 

Insurance 


5/9 

8:45 AM Zukow, Thomas 

DEL/R 

Service garage for Lou 
Fu$2 Dodge 


Dodge Viper with tow 
package installed 

Dealership 


5/9 

10:30 AM Antilles, Wedce 

W/IN 


XCAR 


Corporate 


5/9 

12:00 PM Solo, Hans 



XCAR 

Anything that can make 
the Kessel Run 

Retail 


5/9 

12:15PM Graves, Paul 

CWC 


ICAR 

V6 engine 

Insurance 


5/9 

1:20 PM Jones, Chnstooher 

P/UP 

County Jail 


No bars in windows 

Government 

: : : 

5/9 

1:20 PM Smith, Chris 

W/IN 


CCAR 


Retail 



NoDate, NoTime 

W/IN 




Retail 



"1 


' "otal number of reservations! 10 


Summary Information 



Tkt - 234567 ! cVk - 363221 Transaction Bar 


Jj 


L1.1 Menu Bar 

The Menu Bar will be on all screens and is located at the top of page . The user will use the Menu Bar to navigate to 
different sub-applications (Reservation, Open Ticket, etc) within the ECARS 2.0 system. The options available 
within the Menu bar will be defined bv the System Navigation Team and will not include anv Sub-application 
specific functions such as Complete. Print, and Void . 

112 Summary Navigation Bar 

The Summary Navigation bar is used to navigate through the different screens. For Reservation, the summary 
screens consist of Detail Summary. Forecasting. Notification and Search . These links are included in the tabbing 
sequence and will not have a hot kev associated to them . The Summary Navigation Bar should go just below the 
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Menu bar and will easily distinguish which one of the screens the user is on. 
113 We Bar 

All screens should have a title bar just below the Summary Navigation bar. This is used to text uallv tell the usgr 


114 Summary Information 

The Summary Information section is where the summary information will go. All available remaining space is 
dedicated to this section. This section can include other navigation bars if the specific summary screen requires one. 
One specific navigational button t hat is include d is the " New Reservation" button , This, button wjll.be, available on 
every summ ary screen . The button will have a hot kev and will be l ocated just tQ_the_rjght of any other command 
buttons on the summary screen . When the use r chooses this button, the system will op enjjigw reservation 
transaction. 

115 Transaction Bar 

The current requirement limits the user to three open transactions within one session . The transactions can be in 
anv state: open, closed, or reservation and will be distinguished to the user bv di splaying the transaction number . 
When the user is done working with or editing a transaction, the user is navigated to the home page of the 
Transaction that was closed . The Transac tion Bar will appear on all screens and locate d at the botto m left hand 
most part of the screen. Nothing else should be to the right of the Transaction Bar to allow for the maximum 
number of transactions to be listed . The user can move back and forth from transaction to transaction using alt L 
a!t2oralt 3. 
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1.2 Transaction Screen Layout 

These are the standards for a Transaction screen. A Transaction screen is one that is directly involved in gathering 
information for a transaction or displaying that information. 


'3 Drivers - Microsoft Internet Explorer prsvided fa y Enterprise Rent-a-Car 



James Atteberry 
Additional Drivers: 2 


REFERRAL 


Account Name 
Contact Name 


DATES/RATES 


08/27/2001; ECAR 
Daily Rate; ASD 


BILL- TO 


Account Name 
Contact Name 


199? Dodge Avenger 
Shop Account Name 


Notes Taken: 1 
Changed: 08/27/2O01 

Transaction 
Navigation 
Bar 


Driver * 

Other Address | * 



Cash Qualification 



-Driver Name and Address- 


Last Name * 


Main Screen 

First Name 


'rPhone Numbers - 
Home 


Work 


Extension 

!CZj 


Employer 


1 


Other Phone and Type 


-Home Address- 


Address 


m 

2 

ZIP 

Country 


[United Stegj 

City 

State 

1. 1 i 


-Dnver's License- 



Expiration 

License Number 

Date 

I ii i 


(MM/OD/YYYY) 

State issued 

DOB 



(MM/DD/YYYY) 

SSN 

Height 

1 


Eye Color 

Weight 


n 

Hair Color 





Primary Payment Method 


Transaction Command Bar 


Res- 411781 


Tkt - 234567 [ cbk - 363221 1 Transaction Bar 


1.2.1 Menu Bar 

The Menu Bar will be on all screens and is located at the top of page , The user will use the Menu Bar to navigate to 
different sub-applications (Reservation, Open Ticket, etc) within the ECARS 2.0 system. The options available 
within the Menu bar will be defined bv the System Navigation Team and will not include anv Sub-application 
specific functions such as ( ^mqkte^r int. and Void. 

1.2.2 Transaction Bar 

The current requireme nt limits the user to three open transactions within one session . The transact ions can be in 
anv state: open, closed, or reservation and will be distinguished to the user bv displaying the transaction number ± 
When the user is done working with or editing a transaction, the user is navigated to the home page of the 
Transaction that was closed . The Transaction Bar will appear on all screens and located at the bottom of the 
screen . Nothing else should be to the right of the Transaction Bar to allow for the maximum number of transactions 
to be listed . The user can move back and forth from transaction to transaction using alt L alt 2 or alt 3. 

12.3 Transaction Navigation Bar 

The Transaction Navigation Bar is used to navigate through the main screens of a transaction. The Transaction 
Navigation Bar will not scroll v ertically or h orizontally. 

Each main area within the transaction is broken down within the Navigation, to; . Within each of these areas, the 
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svstem can disDlav a maximum of 2 lines of text . 

If there is a situation where the text exceeds the display area, the 


svstem will truncate anv extra data that exceeds the end of each line (no text wrapp ing) . The user will have the 
ability to view all the data within the are a by the use of hover text. 


The data that will display in each main a rea are the foll owing : 


Screen 

Data 

Driver 

Line 1 - Driver (First Name Last Name"* 

Line 2 - Total number of Additional Drivers. For example 

"Additional Drivers 1" 

Referral 

Line 1 - Referral Account Name 

Line 2 - Referral Contact Name (First Name Last Name) 

Bill-To 

Line 1 - Bill -To Account Name 


Line 2 - Bill - to Contact Name (First Name Last Name) 

Dates/Rates 

Line 1 - Pick-up Date. + Vehicle Class 


Line 2 - Daily Rate + any letter codes** 

Vehicle/Shop 

Line 1 - Year. Make and Model of the Renter's Vehicle 


Line 2 -Shop Account Name 

Notes 

Line 1 - Total number of notes recordedjbc theirjnsactioiL 


Line 2 - Last Modified. Date 


Note: This table will be revisited again during Callbacks. * 

**A letter code will be displayed in the line 2 of the summary area of Rates/Dates when anv of the following events 
occur. 

• If anv additional products are added to the reservation, an "A" will be displayed after the ijaflyjaJg. 

• [fa discou nt is added t o a reservation, a "D" will be displayed after the daily rate. 

• ff a special is added to a reservation, an will be displayed after the daily rate. 

The Transaction Navigation Bar starts at the left edge of the screen, and 25 pixels from the top. It is 125 pixels 
wide, with the attributes defined in the Rentai.css style sheet. 

The Transaction Navigation Bar should be used whenever a transaction has more than one main screen. Most search 
and summary screens will not have a Navigation Bar. 

1.2.4 Title Bar 

All screens s hould have a ti tle bar just below the Menu bar . This is used to tell the user what screen they are on,Jl 
will also contain a Select box with various commands in it , a Go button and a Close button / with an 'X* for the 
label) . The command box should default to u — Options . The command selected will only be executed after the 
Go button is pressed. The Close button will be available on every screen within the sub-application and will close 
the Transaction that the user is working on . When the user selects the "X'\ the svstem will prompt the user that 
thev are closin g the transaction and no data will be saved . The svstem then waits for the user to confirm before 
closing the transaction. 

Currently, the functions that will be available for pilot reservation in the command box will be Void and Print. 
Void will only appear in the command box once the transaction is completed and opened for editing. 

The Title should use the PageHeader style, and be in mixed case. 
12.5 Screen Tab Bar 

The Screen Tab Bar is used when there are multiple instances of the same data (i.e. multiple drivers on the same 
reservation). Tt visually indicates to the user how many copies there are, which copy thev are working with and 
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gives a brief description of each tab. 

For an addit ional driver, the Last Name. First N ame is displayed in the tab area . For each Bi ll-to. the tab will 

The Screen Tab Bar s hould be placed iust belo w the Title Bar for the screen, and can extend the length oflhe 
screen . The background color for the selected tab i s green, w ith white le ttering, w hile the unselected tabs have a 
white back ground and black letters . These attributes are defined in the Rental. ess style sheet. 

126 Screen Navigation Bar 

The Screen Navigation Bar is used when a main screen has one or more sub screens. It consists of a series of 
buttons from left to right.. The name of the sub_§cre en should be appended to the Title Bar . There should be no 
changes to the Screen navigation bar when the user navigates to a sub-screen. The sub-screens can also be 
navigated with hot kevs. 

All of the sub screens are displayed as buttons just below the Screen Tab Bar . If there is no Screen Tab Bar, the 
Screen Navigation Bar should be placed just below the Title Bar. 

12.7 Transaction Command Bar 

The Transaction Command Bar is where the navigation and action buttons for a transaction are placed. When the 
user is on a main screen, the buttons that appear are Previous. Next and Complete . On a sub-screen, this will 
bg Back and Complete . Back will return the user to the main screen . The only wav the user will be able to save a 
transaction is to use the "Complete" button that is located on every screen. , 

When a user chooses to complete a transaction, the system will display a confirmation the transaction was save 
successfully and the syst em will return the user to the sub-application home screen. 

The Transaction Command Bar should be placed just above the Transaction Bar, and to the right of the Nayjgatol 
Bar. It e xtends all the wav to the left . 

12.8 Main Screen 

The Main Screen uses all remaining space. This is where the actual content should go for the screen. There should 
never be a horizontal scroll bar, but a vertical scroll bar is acceptable for the main screen . Within the screens, all 
the pop-up/dialog boxes should act the same way . The standards for dialog boxes/pop-ups are the following: 

> boxes will behave dependant on the function of the box . 


If the box is display only, a close button will be available 
If the box has input criteria, an "OK" and "Cancel" button will be available 
If the box has only links, a "Cancel" button will be available 
No hot keys will be available for the action buttons He. Ok. Close. Cancel) 
AH boxes will have an "X" in the corner that closes box. 
The box will close if the user clicks outside of the box. 

Each dialog/pop-up will have a default Ok or Cancel that will fire when the user hits enter. This 
will occur on all dialog/pop-up boxes except for when the following occurs: 

a. The entry field of the search criteria requires the use of more than one line, fie: an address 
fiekft 

b. There is validation on the criteria that is being entered, (ie. More that one criterion must be 
entered. A last name and a first name must be entered etc.) 

An example of a default Ok would be when a user is adding a new contact. As soon as the user enters data into 
any of the fields and hits enter, the dialog/pop-up will fire the Ok button automatically. Default Cancel will be 
used whenever a user tries to exit the sub-application or needs to confirm an action. 
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1.3 Summary Search Scree n Layout 

These are the standards for a Search screen that is used to locate a specific transaction. 


3 Reservation Search fritcric ~ Advanced - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 


Retail 


Summary Forecasting Notification 


search ! Summary Navigation Bar 


[(Reservation Search 


I Sroup: 


Center Last Name: 


Branch: 


01 -St. Louis 


The First Branch 


Search Filters 

Simple Search 


Renter First Name: Renter Telephone Number: 


Reservation Number: 

I 


-Bill-To and Shop Customers 

® Account Name: O Customer Number: 


Claim/Policy/P.O. Number: 


Search Criteria 

Renter's License Plate: 



1022 02/28/01 8 1 . 30 AM , Smith, Roaeg^y^ - ftgg llft f >C -— P 


MVAR 


103 453 


1022 


03/01/01 


8)00 AM Tucker, James 


Pick-Up 


ECAR 


Insurance fi 103029 


1022 


03/01/01 


lliOOAM Smith, Robert 


Walte-Ir. 


FCAR 


Fleet 


Q345T1 


1022 


03/05/01 


8s00 AM Verhoist, Laura 


Deliver 


ECAR 


104439 


[terns 1 - 10 of 50 found 


Search Results Navigation 

Prev 12 3 4 5 Next 


Re*> 411781 


Tkt - 234S&7 cbk - 363221 Transaction Bar 


1.3.1 Menu Bar 

The Menu Bar will be on all screens and is located at the top of page . The user will use the Menu Bar to navigate to 
different sub-applications (Reservation, Open Ticket, etc) within the ECARS 2.0 system. The options available 
within the Menu bar will be defined bv the System Navigation Team and will not include anv Sub-application 

13.2 Transaction Bar 

The current requirement limits the user to three open transactions within one session . The transactions can be in 
anv state: open, closed, or reservation and will be distinguished to the user bv displaying the transaction number. 
When the user is done working with or editing a transaction, the user is navigated to the home page of the 
Transaction that was closed . The Transaction Bar will appear on all screens and located at the bottom of the 
screen . Nothing else should be to the right of the Transaction Bar to allow for the maximum number of transactions 
to be listed. The user can move back and forth from transaction to transaction using alt 1. alt 2 or alt 3. 

1.3.3 Summary Navigation B?r 

On the Transaction Search screens (Open Ticket, Reservation and Closed Ticket (not developed yet)), the user will 
have to use the Summary Navigation Bar to move between the screens. There will be no cancel or back button 
available to the user . The Summary Navigation bar is used to navigate through the different screens. Epx 
Reservation, the summary screens consist of Detail. Summary. Forecasting. Notification and Search . These buttons 
are included in the tabbing sequence . The Summary Navigation Bar should go just below the Menu bar. 
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13.4 Title Bar 

All screens should have a title bar just below the Summary Navigation bar. This is used to tell the user what screen 
they are on. The Title should use the PageHeader style, and be in mixed case. 

13.5 Search Res ults Navigation 

One specific navigation al button t hat is included in this area is the "New Reservation ' button . This button will be 
available on every summ ary screen . The button will have a hot key and will be located just to the right of any 
other comm and butt ons on the summary search scree n . When the u ser choos es this button, the system will open a 
new reservation transaction . 
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1.4 Transaction Search Screens 

Within a transaction, there are a couple of search screens. These searches will navigate a little differently than the 
Summary Search Screens. Currently, the Transaction Searches are: Driver, Account, and Employee. 


•^Jbrtwr Search - Microsoft In-ternc* Explorer provided by Enterprise Rent-a-Car 



Driver summary 1 
Driver summary 2 


REFERRAL 


Referral sum 1 
Referral sum 2 

ill 

Dates summary 1 
Dates summary 2 


BILL-TO 


Bill-To summary 1 
Bill-To summary 2 


VEHICLE/SHOP 


Vehicle/Shop 1 
Vehicle/Shop 2 


Notes summary 1 
Notes summary 2 

Transaction 

Navigation 

Bar 


Driver Search 


Telephone 


Last Name 


First Name 


Drivers License Number Date of Birth 


Search Criteria 



Atteberrv, Jamas 2002 Mateus Apt B, Maryland Heights (444) 444-4444 (H) 1 l/20/l 97 1 

(314) 512-3479 (W) 


Bond, James 


Classified, Unknown 


Doe, Jane 


123 West Main, Anywhere 


1/2/1943 


Jenssn, Seoroa 


5 Spacely, Apt 4, Sprockets 


(213) S47-4798 4Ht45678(W) 
(541) 789-1234(0) 


tobochecski,, Steve 


Search Results 


Mathews, Mike 


Puiols; Albert 


Sattaluri, Chakravatthy 


Smith. Ozzie 


Items 1 - 10 of 10 found 


Search Results Navigation 

Prev 1 Next 



el 


$1 


14.f Mew Bar 

The Menu Bar will be on ail screens and is located at the top of page. The user will use the Menu Bar to navigate to 
different sub-applications (Reservation, Open Ticket, etc) within the ECARS 2.0 system. The options available 
within the Menu bar will be defined by the System Navi gation/T eam and will not include anv Sub-application 

14.2 Transaction Bar 

The current requirement limits the user to three open transactions within one session . The transactions can be in 
anv state: open, closed or reservation and will be distinguished to the user bv displaying the transaction number . 
When the user is done working with or editing a transaction, the us er is navigated to the home page of the. 
Transaction that was closed . The Transaction Bar will appear on all screens and located at the bottom of the 
screen . Nothing else should be to the right of the Transaction Bar to allow for the maximum number of transactions 
to be listed. The user can move back and forth from transaction to transaction using alt h alt 2 or alt 3 . 

14.3 Title Bar 

All screens should have a title bar just below the Menu bar. This is used to tell the user what screen they are on . U 
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will also contain a Select box with various commands in it . a Go button and a Close bu tton (with an 'X' for the 
laML The functions that will be available for pilot reservation in the command box will be Void and Print . Void 
will only appear in the command box once the transaction is completed and opened for editing . The command box 
should default to " — Options » The comma nd selecte d will only be executed after the Go button is pressed . The 
Close button will be available on every screen within the sub-application and will close the Transactio n that the 
user is working on . When the user selects the U X". the system will promp t the user that they are closing the 
transaction and no data will be saved . The system t hen waits for the user to confirm befo re closing; the transaction. 

The Title should use the PageHeader style, and be in mixed case. 
1.4.4 Transaction Command Bar 

The Transaction Command Bar is where the navigation and action buttons for a transaction are placed. When the 
user is within a tran saction search screen, the buttons that appear are Cancel and Complete . T he Cancel button 
returns the user to the screen where the search was initiated . For Driver search, the business re gmr^eriLisJaJiaye 
the text changed to t6 New Driver" ra ther than Can cel 

The Transaction Command Bar should be placed just above the Transaction Bar, and to the right of the Navigation 
Bar. It extends all the way to the left. 

1.5 Tabbing 

Tabbing will follow the requirem ents noted below . 

a. Tabbing will always go and left to right top to bottom within each defined area on the screen. fUnless a 
specific business requirement drives a modification^ t 

b. Summary screen tabbing will start at the first data entry field or button and will end with the screen 
command buttons on the bottom before the transaction bar. The next tab will be the Summary Navigation 
Bar. This tabbing sequence will not include the system menu or the transaction bar. 

c. Transaction tabbing wilt start at the first data entry field or button within the screen and will end at the 
complete button. The next tab takes the user to the upper most left h and field/button on the scre en. It will 
not go to th e system menu, the transaction navigation bar, or the transaction bar . 

d. The Transac tion navigatio n bar and the transaction bar will be accessed via hot keys. When a hot kev is 
used in thes e instances, the system will navigate to the s pecific functional area or will changgij^agtions^ 
Users will not b e able to u$e t he arrow keys for navigation within the navigation bar. 

1.6 Hot Kevs 

Hot Kevs within the sub-applications will be accessed bv ALT + a letter or number , Hot Kevs for the system will 
be accessed bv CNTL + a letter or number . Once the sub-application is translated, the hot keys will be redefined to 
accommodate the translations, 

The following standards were determined for the use of hot keys: 

1. Summary Screens 

a. Hot keys will be on the buttons only. 

2. Transaction Screens 

a. No hot keys will be set for the screen tab bar. They will be part of the tabbing sequence. 

b. The Transaction Navigation Bar will have hot keys 

c. The screen navigation bar will have hot keys 

d. The open transactions in the Transaction Bar will be set to Alt 1, Alt 2, Alt 3, but will not be 
visually seen by the user. 

3. Dialog/ Pop-up boxes will not have hot keys on the action buttons, (i.e. Cancel, Ok, Close) 
See Hot Kevs Grid for the exact hot key layout for Pilot Reservation 

1.7 Miscellaneous Notes 

Below are some other notes regarding lay out that were driven out during the meetings: 
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1. The Transa ction Navigation bar must be blue. The Screen Tabs and the Transaction Bar are colored a 
different shade of green from the rest of the sub-app. 

2. The Additional Driver button will be located in the screen tab area on the far right 

3. Add new contact buttons will be relabeled t; New Contact" and a new auth bv will be relabeled "New Auth 

ML 

4. Renter's Vehicle and Shoo were combined to make one main screen c alled "Vehicle/Shop" 

1.8 Questions 

• Do you want a new reservation button in the Res Sumary Package? 

o Yes. On all screens 

• Do you want to designate a home page for all the sub-applications? Our concern is that the maintenance 
programs will need a home page that is security based. 

o Each sub-application will determine this. 

• When the user switches to another open transaction, where should the user's focus be? 

o The user should be returned to the same screen that was active when the user changed 
transactions. 
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Screen Action Specification 

1. introduction 

This document will describe the behavioral characteristics associated with the Additional Drivers screen. 


The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 

2. Additional Driver Screen 



James Atteberry 
Additional Drivers: 2 


REFERRAL 


Account Name 
Contact Name 


DATES /RATES 


08/27/2001; ECAR 
Daily Rate; ASD 


BILL-TO 


Account Name 
Contact Name 


VEHICLE/SHOP 


1997 Dodge Avenger 
Shop Account Name 


Notes Taken? 1 
Changed: 


Driver 


Other Address 


Insurance Detail 


Cash Qualification 


r Driver Name and Address- 


Last Name 


First Name 


|Chris 


Chris 


r Phone Numbers - 
Home 


Work 


Extension 


Employer 


[ 


Other Phone and Type 

3C 


-Home Address 

Same as Renter D 
Address 


ZIP 


Country 

H t. United ste i 


•Driver's License 




Expiration 


License Number 

Date 


1 11 


(HM/D D/YYYY) 

Issuing Country 

Issuing State 



SSN 

DOB 
-1 



J (MM/D D/YYYY) 

Eye Color 

Height 



nn 

Hair Color 

Weight 

n 




Figure 1 - Additional Drivers Screen 
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3. Reservation Number 

3.1 Behavior 

This area shows the uni q ue reservation numb er that has been assigned to the newly created 
reservation. The reservation number is 6 alphanumeric cha racters long. If another reservation is 
open, its reservation number will be di splayed in th is area as well. The u ser will have the ability 
to have u p to 3 reservations open at a time. A hyperlink will be available on the r eservation 
numbers of the reservations that are NOT curren tly being displayed. For the reservation that is 
currently displayed, the reservation number will not have a hyperlink available . This is to allow 
the user to navigate between the open reservations. 

3.2 Validation 

None identified at this time. 

3.3 Business Exceptions 

If the user tries to open a 4 th reservation, the system will disolav a message stating, "A maximum 
of 3 reservations mgy be displayed". 

3.4 System Exceptions * 

None identified at this time. 

4. Additional Driver Bar Area 

4.1 Behavior 

T^^^^mM^hM^m^LDm ^T Title Bar will allow the us^Q_^oesslr^isag tion-wide functions. 
These functions for Reservation are: ~ Options --. Print. Void and Transfer . Th^je_Mlj^ 
Options The user must press the Go button to initiate the selected function. 

The Title Bar Button area in the Additional Driver Title Bar contains two buttons - a Go button and a Close . 
button. 

The Go button is ^lmys^jye^aMJ^ed t o initiate a function selected in the Option area . 

The Close button is always active and is used to close the current transaction. The button is labeled with an 
'_XL Pressing this button will cause a confirmation popup, asking the user if thev wish to cancel the 
transaction and lose all changes. If the user selects 'No*, thev returned to the same screen. If the user 
selects 'Yes*, the transaction is closed with no changes saved to the database. 

4.2 Validation 

None identified at this time. 

4.3 Business Exceptions 

None identified at this time. 

4.4 System Exceptions 

None identified at this time. 
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5. 

5.1 


5.2 
5.3 
5.4 

6. 
6.1 


Button Line Area 

Behavior 



e the user to the notes screen witfaii 


The Next bu- 


ame transaction 


The Complete button will i nitiate a save of the transact ion. All validations will be performed, 
errors to the user. If there are no errors, the transaction is saved, and the user is returned to the Reservation 
home page. 

Validation 

None identified at this time. 

Business Validation 

None identified at this time. 

System Validation 

None identified at this time. 

Driver Navi gation Area 

Behavior 

This area gi ves the user th e ability to move to anv sc reen within the Driver^rea. Each screen 
within the Driver area is connected bv a hyperlink. Th e screens that have been defined are: 
Drivers. Other Address. Insurance Detail, an d Cash Qualification A hyperlink will NOT be 
available for the screen that is currently displayed. 


6.2 Validation 

None identified at this time. 

6.3 Business Exceptions 

None identified at this time. 

6.4 System Exceptions 

None identified at this time. 

7. Update Button Function 

7.1 Behavior 

All information th at is initially pressed in this panel will he "read only" This button must be 
sheeted before the user can edit an y of th e informatio n If the user has selected this button and 
mnves to a different panel the panel will still be in the *dit mode when the user returns to it 
Similarly, if the button is nnt selected a nH the user moves to another panel the panel will still be 
in the "read only" mode when thp nser returns to it 

7.2 Validation 

None identified at this time, 

7.3 anginas Exceptions 

will not he en°^ {f rt" huttQ " * not selected. 
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7.4 System Exceptions 

None identified at this time. 

8. Clear Button Function 
8.1 Behavior 

All information that is initially presented in this pa nel will be "read only". If this button is selected, 
ail if the information areas on the panel wilt be cleared and will be available for input. This will 
have the same fun ctionality as add in g a new driv er to the reservation. If the user has selected this 
hntton and mov es to a different pa nel the panel will still be in the edit mode when the user 
returns to it. Similarly if the button is not selecte d and the user moves to another panel, the panel 
will still be in the "read only" mode when the user returns to it. 


8.2 Validation 

None identified at this time. 

8.3 Business Exceptions 

None identified at this time. 

8.4 System Exceptions 

None identified at this time. 

9. Delete Button Function 

9.1 Behavior 

un^n the Delete button is y, r - r,1 thr irrr '"ill hr pirnr*" 1 - ™«™ <*"™™ " f ™ e additlonal L 
driver (-Are vou snre von wish to r emove. FIRST NAME [ .AST NAME from the reservation? ). KM 
request is confirmed, the additional driver k removed fr om the reservation The user IS then take to the 

main driver ™* e ^* main renten . Tf ^ lieSt is C 8nnft11ftri - the ™ eT ™ ]] °" thg main 

Note that the main driver is NOT consid ered an additional driver, and thus cannot he removed from the 
reservation. 

9.2 Validation 

The user must confirm that the delete request 

9.3 Business Exceptions 

None identified at this time. 

9.4 System Exceptions 

None identified at this time. 

10. nriver's Last and First Name 

10.1 Behavior 

This area is divided into two fields. 

• Last Name 

• First Name. . 

Rnth tehte are fre e farm tevt fields and may contain alphanumeric values. 

10.2 Validation 

if th» , ,rer attempt* tn *vif the screen .r r.nmnlete the m^nr ntion the last name field mi ist have values 
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entered. If there are not val ues in the last n ame field, the system will display a message "Last Name is 
required for a Reservation". ***See Error Message Spec 


10.3 Business Exceptions 

None identified at this time. 

10.4 System Exceptions 

None identified at this time. 

11. Address Same as Driver Checkbox 

11.1 Behavior 

This checkbox will indicate if this additional driver should have the same address as the Renter. 
When the button is checked, the Address. Country. Zip. City and State fields are set to their 
default values (bl ank or the initia l value if this is a select boxl The fields are also disabled. 

When the checkbox is uncheck ed, the fields are enabled for input. 

11.2 Validation 

None identified at this time. 

11.3 Business Exceptions 

Tf this hotton is selected, and there is not anv addre ss information in the first drivers address areas, a 
message is displayed "No Driver Addr ess Information Available". 

1 1 .4 System Exceptions 

None identified at this time. 

12.1 Behavior 

This area is a free form alphanumeric area. This area is disabled if the Address Same as Driver 
check box has been selected. 

12.2 Validation 

None identified at this time. 

12.3 Business Exceptions 

None identified at this time. 

1 2.4 System Exceptions 

None identified at this time. 

13, Zi p Code. Country. Citv and State 

13.1 Behavior 

These behaviors are detailed o ut in the Geo-Fr amawork Search Screen Spec These areas are 
disabled if the Address Same as Driver check box has been selected. 

13.2 Validation 

None identified at this time. 

13.3 Business Exceptions 

None identified at this time. 
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13.4 System Exceptions 

None identified at this time. 


14. Home Phone Area 

14.1 Behavior 

The Home Phone area is a free form text area that will allow the user to input alphanumeric 
values. 

14.2 Validation 

None identified at this time. 

14.3 Business Exceptions 

None identified at this time. 

14.4 System Exceptions 

None identified at this time. 

15. Work Phone Area 

15.1 Behavior 

The Work Phone area is a free form text area that will allow the user to inpat alphanumeric 
values. 

15.2 Validation 

None identified at this time. 

15.3 Business Exceptions 

None identified at this time. 

15.4 System Exceptions 

None identified at this time. 

16. Phone Extension Area 

16.1 Behavior 

The Phone Extension area is a free form text area that will allo w the user to input alphanumeric 
values. This area would not be en abled until them was a value entered into the Work Phone 
area. 

16.2 Validation 

There must be a value in the Work Pho ne area before this area is enabled. 

16.3 Business Exceptions 

None identified at this time. 

16.4 System Exceptions 

None identified at this time. 

17.1 Behavior 

The Employer area is a free form te xt area that will allow the user to input alphanumeric values. 
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17.2 Validation 

None identified at this time. 

17.3 Business Exceptions 

None identified at this time. 

17.4 System Exceptions 

None identified at this time. 

18. Other Phone Area 

18.1 Behavior 

The Other Phone area is a free form text area th at will allow the user to input alphanumeric 
values. 

18.2 Validation 

None identified at this time. 

1 8.3 Business Exceptions 

None identified at this time. 

18.4 System Exceptions 

None identified at this time. 

19. Phone Type Area 

19.1 Behavior 

This area will he a drop down area that will d efault to a blank. When the user clicks the drop 
down area, the system will dis pla y the dom ain of Phone Types available. 

19.2 Validation 

Tf there is a value en tered in the Other Phone area, then a type other than blank must be selected. 

19.3 Rinsings Exceptions 

If values exist within t he Other Phone area the system will also verify that a value, other than 
hlank has been sele cted from the d rop down area Phone Tvoe. If one has not been selected, 
the system displays a message "Phone Type must be selected". 

1 9.4 System Exceptions 

None identified at this time. 

20. License Number 

20.1 Behavior 

This area will allow entry of alphanume ric values. 

20.2 Validation 

If values are ent ered into anv o ne or combi nation of Expir ation Date. State Issued and/or Date of 
Rirth then Licens e Number is als o required. The system will check which of these four areas 
contain or do not contain values and will present the user with a message stating which area(s) 
need to have a value Example, if Expiration P *** state issued contain values and Date of 
Rirth and License Number do not, the system can display a message stating 
"Missin g Information in: 

♦ Date of Birth 

• I icense Number" 
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In this example the list wouid state that required inform ation is missing for License number and 
Hate of Birth, but it could be anv combination of the four. 

20.3 Business Exceptions 

if values are entered into the License Number area then the Expiration Date. State Issued and 
Date of Bi rth areas become required. f 

20.4 System Exceptions 

None identified at this time. 

21. Ex piration Date 

21.1 Behavior 

This will be a num eric field. It will not be for matted for presentation purposes. The user may enter 
delineating characters, but these will be stripped out before committing the data to the database. (As 
determined for all locale specific formatting.) 

21.2 Validation 

This date cannot b e less than or equal to the cu rrent date. If it is a message is displayed stating, 
'Driver Licen se Ex piration Date is Invalid". 

If values are ent ered into any one or combination of Licen se Number State issued and/or Date of 
Rirth 1 then Ex piration Date is also required. The system will check which oifhese four areas 
contain or do not contain values and will present t he user with a message stating which area(s), 
need to have a value. See example with License Number 

21.3 Business Exceptions 

if values are entered into the Expiration Date then t he I icense Number. State Issued and Date of 
Birth areas b ecome required. 

21 .4 System Exceptions 

None identified at this time. 

22. State Issued 

22.1 Behavior 

Thk search criteria area will be a d ro p-down box. It should default to a blank. The users would also like, to 
have the ability to type a character alpha or numeric, into the criteria area and have the drop down list 
position to the character. (If the u«»r »" the drop down list would position to the first State 

harming with "H" in the lisfl 

22.2 Validation 

If values are entere d into any one or combination of License Number Expiration Date, and/or 
nate of Birth, then S tate Issued is als " f^inrpri The system will check which of these four areas 
nnntain or do not contain values and will prese nt the user with a message stating which area(S) 
need to have a value. See example with License 

22.3 Business Exceptions 

tf | state is selecte d from this drop down area, then the Fx piration Date. License Number and 
Hate of Birth areas heoome required. 

22.4 System Exceptions 

None identified at this time. 
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23. Date of Birth 

23.1 Behavior 

This will be a numeric field. It will not be formatted for presentation p urposes. The user mav enter 
delineating characters, but these will be strinned out befo re committing the data to the database. ( As 

23.2 Validation 

If values are entered into anv one or combination of Expira tion Date. State Issued and/or License 
Mumber, then Date of Birth is also renuired. The s ystem w ill check which nf these four areas 
contain or do not contain values and will prese nt the user with a message stating which area(s) 
need to have a value. See evample with License 

23.3 Business Exceptions 

If the Date of Birth en tered calculates to being equal to or greater than 70 years of age, the 
system displa ys a message "Aae is over a ge restriction" The user mav continue, change the 
DateofRirth or cancel. 

If the Date of Birth entered calculates to being b etween the ages of 18 to 20 the system displays 
a message "Aae is u nder aoe restri c tion" The user mav continue, change the Date Of Birth Of 

if the nate of Birth entered calculates t n being between the ages of 21 to ?A the system displays 
a message "Aae is u nder aoe restrict ion" The user mav continue, change the Date of Birth or 

Qancel 

Tr^While these are now identic* ! be h aviors, i n the future, different groups want to have the 
ability tn have different actions and messages for these 2 age groups,) 

if the Hate of Birth entered calculates tn being equal tn, or less than. 17 years of age, the system 
displays a message "Age is under an e restriction" The user mav NOT continue, they must 
change the Date of Birth or cancel, 

Ifajs become required* 

23.4 System Exceptions 

None identified at this time. 

24. Sncial Security Number 

24.1 Behavior 

This area will allnw entry of alphanumeric values. 

24.2 Validation 

None identified at this time. 

24.3 Business Exceptions 

None identified at this time. 

24.4 System Exceptions 

None identified at this time. 


Confidential 


©<Company Name>, 2000 


Page 15 


<Project Name> 

Version: <1.0> 

Supplementary Specification 

Date: <dd/mmm/yy> 

<document identified 


25. Height 

25.1 Behavior 

This will be two areas, in North Ame rica one for feet and the other for inches. It will allow entry of 
numeric values. 

25.2 Validation 

None identified at this time. 

25.3 Business Exceptions 

None identified at this time. 

25.4 System Exceptions 

None identified at this time. 


26. Eve Color 

26.1 Behavior 

This search criteria area will be a drop-down box. It shoi'™ ^fimlt to a blank The users would also like to 
have the ability to type a character, alpha or numeric into the criteria area and have the drop dawniist 
position to the character, gf the user enters an *H" t h e dro p down list would position to the first state 
banning with "H" in the list) 

26.2 Validation 

None identified at this time. 

26.3 Business Exceptions 

None identified at this time. 

26.4 System Exceptions 

None identified at this time. 

27. Weight 

27.1 Behavior 

This area will allow entry of numeric values. 

27.2 Validation 

None identified at this time. 

27.3 Business Exceptions 

None identified at this time. 

27.4 System Exceptions 

None identified at this time. 

28. Hair Color 
28.1 Behavior 

m -nrrh rn^nnn^^^^^ Tt should default to «, hhnV The users jmM ate like to 
Z J thP ability to tvne a c haracter, alpha or nu meric, into the rrjteri. area and have the drop > do wn ist 
ILl^ ^ ,L\LSL nf L.r, aT^the dropjfo™ list would nositWto the first state 
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28.2 Validation 

None identified at this time, 

28.3 Business Exceptions 

None identified at this time. 

28.4 System Exceptions 

None identified at this time. 

29. Button Line Area 

29.1 Behavior 

The Cancel image/button display the previo us panel without sav in g anv changes prio r to the last save. 
The Additional Drivers image/button will invoke the additional driver panel submitting the form to the 

29.2 Validation 

None identified at this time. 

29.3 Business Exceptions 

t 

None identified at this time. 

29.4 System Exceptions 

None identified at this time. 

30. Rules 

30.1 Behavior 

If there is a re nter warning concerning the Driver, a renter warning message, similar to the one shown 
below, shoul d be displayed. It should be default ed to the "Do Not Rent" selection. The user may override 
bv making the "Renf * selection. 

If the "Do Not Rent" is sele cted, the syst em returns to the Reservation Home Panel. 
If the "Renf ' is selected, the system returns to original panel. 

30.2 Validation 

None identified at this time. 

30.3 Business Exceptions 

If the user choo ses the "Rent" selection, a system note is generated. (See Notes Use Case for specifics.! 

30.4 System Exceptions 

None identified at this time. 
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Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the GEO Framework aspects on 
all types of address screens. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 


2. GEO Framework Choices Screen 


<3 Multiple Cities Found - Microsoft Internet Explore! provided by _Entegpr«eJ^rrt^-Caf 



-Addi«S|^lV\APPS\Ecas 20\Developrnert Projects\HTML\Reservarion\Ba*ic R ^^ation^MultGeoHite.htfnl 



Mulitple Cities Found 


More than one city has been found for this Zip Code. 
Please select a city from ths list below. 


StLouis. Missoun 
Maryland Heights, Missouri 
Creve Coeur, Missouri 
Bnd^etimMissouri 


Figure 1 - GEO Framework Screen 
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3- Zi p Code Area 

3.1 Behavior 

This will be an alphanumeric area. The user will enter a zi p code and then have the option to 
invoke the GEO Framework search or not. The GEO Fra mework search is to locate a Citv and a 
State associated with the zip c ode entered. 

If the GEO Framework search is selected, three res ults might happen: 

1. There are not anv matches to the values entered. If this happens, a message is displayed 
"No matches were found for zi p code." 

2. There is a single match to the values entered. If this happens, the Citv and State areas 
are populated with the match values found. 

3. There are multiple matches to the value s entered. If th is happens, the user is presented 
with the panel in 2. above , and the user must make a selection and click on the Ok 
button. The svstem will then populate the City and State areas with the selected values. 

If the GEO Framework is not se lected the system accepts values entered. 

3.2 Validation 

None identified at this time. 

3.3 Business Exceptions $ 

None identified at this time. 

3.4 System Exceptions 

None identified at this time. 


4. Country Area 

4.1 Behavior 

This search criteria area will be a dro p-down boy it shnnM be defaulted to the Country of the terminal 
locale on in itial entry or navigation to an address panel 

Tbe users wo uld also like to have the ability to type a character, alpha or numeric, into the crit 
have the drop down list positio n to the charac ter. Hf the user enters an "H" the drop down list would 

4.2 Validation 

None identified at this time. 

4.3 Business Exceptions 

None identified at this time. 

4.4 System Exceptions 

None identified at this time. 

5. Citv Area 

5.1 Behavior 

This area is a free form alphanumeric area, _^ liMr 
If the GEO Framework search has heen selected and a single value was found, or the user 
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selected a value fro m the list, then t his area will be populated with that value. 

Even though a value mav be populated bv the system, the area still may be changed or edited. 

5.2 Validation 

None identified at this time. 

5.3 Business Exceptions 

None identified at this time. 

5.4 System Exceptions 

None identified at this time. 

6. State Area 

6.1 Behavior 

This search criteria area will be a drop-dow n box. Tt should be defaulted to a blank. 

If the GEO Framework search has been select ed and a single value was found, or the user 

selected a val ue from the list then this area will be populated with that value. 

The users would also like to have the ability t o ty pe a chara cter, alpha or numeric, into the criteria area and 

have the drop down list position to the ch aracter (Tf the user enters an "H" the dron down list would 

position to the first state beginning with "H" in the list. 

6.2 Validation 

None identified at this time. 

6.3 Business Exceptions 

None identified at this time. 

6.4 System Exceptions 

None identified at this time 

7. Button Line Area 

7.1 Behavior 

The Cancel imag;e/button will r^nv. this imae;e and present the previous panel. 

The Ok imaae/button will take the selected citv and state and populate the Citv and State areas within the 
original address panel with t he values selected. 

7.2 Validation 

None identified at this time. 

7.3 Business Exceptions 

None identified at this time. 

7.4 System Exceptions 

None identified at this time. 

8. Rules 

None identified at this time. 

9. Security 

The user must have the appropriate securi ty Wei to access this screen. The user is allowed to view or print 
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anything. It i s when they attempt to edit a reservation that their security restrict ions will be enforced 
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Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the Other Address screen. 


The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 


2. Other Address Screen 


DRIVERS 


James Atteberry 
Additional Drivers: 2 


REFERRAL 


Account Name 
Contact Name 


DATES /RATES 


08/27/2001; ECAR 
Daily Rate; ASD 


BILL-TO 


Account Name 
Contact Name 


VEHICLE/SHOP 


1997 Dodge Avenger 
Shop Account Name 


Notes Taken: 1 
Changed: 08/27/2001 


Drivers - Other Address 



Atteberry, 
James 


Smith, 

Chris 


Cloud, 
Kevin 


Driver 


Other Address 


Insurance Detail 


r. 


Cash Qualification 


Other Address- 
Address Type 


Address 


V 


ZIP 


City 


Country 


State 

1 Alabama " 


Res- 411781 


Tkt - 234567 Cbk - 363221 


Figure 1 - Other Address Screen 
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3. Reservation Number 

3.1 Behavior 

This area shows the unique reservation number that has been assigned to the newly created 
reservation. The reservation number is 6 alphanumeric characters long. If another reservation is 
open, its reservation number will be displayed in this area as well. The user will have the ability 
to have up t o 3 reservations open at a time. A hyperlink will be available on the reservation 
numbers of the reservations that are NOT currently being displayed. For th e reservation that is 
currently displayed, the reservation number will not have a hyp erlink availab le. This is to allow 
theuserto naviga te between the open reservations. 

3.2 Validation 

None identified at this time. 

3.3 Business Exceptions 

If the user tries to open a 4 th reservation, the system will display a message stating "A maximum 
of 3 reservations mav be displayed". 

3.4 System Exceptions 

None identified at this time. 

4. Other Addr ess Title Bar Area 

4.1 Behavior 

The o ption area in the title bar will allow the user to access transaction-wide functions. These functions for 
Reservation are: -- Options ~. Print. Void and Transfer. The default option is Options The user 
must press the Go button to initiate the sel extedJmctiojL 

The button a rea in the title bar contains two buttons - a Go button and a Close buttoiL 

The Go butto n is alwa ys active, and is used to initiate a function selected i n the option area. If the selected 
option is "—Options nothing should happen. 

The Close button is always active and is used to close the current tra nsaction. Th e button is labeled with an 
fc X'. Pressing this button will cause a co nfirmation popup, askin g the user if thev wish to cancel the 
transaction and lose all changes. If the user selects 'No', th ev are returned to the same sgreerL If the user 
selects c Yes 5 . the transaction is closed with no changes saved to the da tabase and the user is taken to the 
Reservation home page. 

4.2 Validation 

None identified at this time. 

4.3 Business Exceptions 

None identified at this time. 

4.4 System Exceptions 

None identified at this time. 
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5. Driver Tab Navigation Area 
5.1 Behavior 

This area contains a tab for each driver on the transaction. The first tab is the primary renter , with all other 
tabs being additional drivers. The name on the tab will be the Last Name on the top and the First Name on 
the bottom of the tab. 


By clicking on a tab, the mai n driver screen for that driver will be brought up. 

5.2 Validation 

5.3 Business Exceptions 

5.4 System Exceptions 

6. Driver Navigation Area 

6.1 Behavior 

Ih&area gives the user the ability to move to anv screen within the Driver area. Each screen 
within the Driver area is connected by a hyperlink. The screens that have been defined are: 
Driver. Other Address. Insurance Detail, and Cash Qualific ation. A hvoerliftk will NOT be 
available for the screen that is currently displayed. 

6.2 Validation 

None identified at this time. 

6.3 Business Exceptions 

None identified at this time. 

6.4 System Exceptions 

None identified at this time. 

7. Other Address Area 

7.1 Behavior 

This area is a free form alphanumeric area. 

7.2 Validation 

None identified at this time. 

7.3 Business Exceptions 

None identified at this time. 

7.4 System Exceptions 

None identified at this time. 
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8. Other Addre ss Type Area 

8.1 Behavior 

This search criteria area will be a drop-down box. The users would also like to have the ability to type a 
character, alpha or numeric, into the cr iteria area and have the drop down lis t position to the character. (If 
the user enters an "FT the drop down list would position to the first state beginning with *H" in the list. 
Valid values are Home. Business. Local a nd Other. 

8.2 Validation 

None identified at this time. 

8.3 Business Exceptions 

None identified at this time. 

8.4 System Exceptions 

None identified at this time 

9. Citv. State. Zip Code and Country, and Citv Other. State Ot her. Zip Code 
Other and Country Other Areas 

9.1 Behavior 

These behaviors are detailed out in the Geo-Framswork Search Screen Spec 

9.2 Validation 

None identified at this time. 

9.3 Business Exceptions 

None identified at this time. 

9.4 System Exceptions 

None identified at this time. 

10. Button Line Area 

10.1 Behavior 

The Back button will take the user back to the main dri ver screen for the currently selected driver. JM 
Com plete button will initiate a save of the transaction. All validations will be performed, returning any 
errors to the user. Tf there are no errors, the transaction is written to the database and the user is returned 
to the Reservation home page. 

10.2 Validation 

None identified at this time. 

10.3 Business Exceptions 

None identified at this time. 

10.4 System Exceptions 

None identified at this time. 

11. Rules 

None identified at this time. 
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12. Security 

The user must have the ap pro priate security level to access this screen. The user is a llowed to view or print 
anything. It is when thev attempt to edit a reservatio n that their security restri ctions will be enforced. 
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Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the Quote a Rate screens. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 


2. Dates and Rates - Screens 


Ute i-a vfe W 'look W ': -;ry/-r; 



fllli^^ 


"3 


Nervation 


DRIVERS 


Driver summary 1 
Driver summary 2 


REFERRAL 


Referral sum 1 
Referral sum 2 


P 


Dates summary 1 
Dates summary 2 


BILL-TO 


Bill-To summary 1 
Bill-To summary 2 


VEHICLE/SHOP 


Vehicle/Shop 1 
Vehicle/Shop 2 

Notes summary 1 
Notes summary 2 


.... " .->-,-' , 


Rates/Dates 


-Pickup 

Branch: 0101 LADUE 
Data: Time: 


- Return 

Branch: 0101 LADUE 
Date: Time: 


MM/DD/YYYY 
Method: 


HH:MM A 
Location: 



MM/DD/YYYY 

Method: 

I 53 


HHlMM A 
Location: 


rRate Source— 
Account Name 

Rate Plan 
{-Select-""" 


Account Number 

C 

Car Class 


Rental Type 


[ 


r Rates - 



15.99! I 1501 1 59.93' j] 750] | jjSgj H 1 5001 1 5 - 99 ; 


JQ.15j O 


Tkt - 234567 Cbk - 363221 


.jrf 


flQBHHra 
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*3 Enterprise^ ECARS Application - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 


drivers bates/Rates 


-Options- 


REFERRAL 


DATES/RATES 


10/11/2001 


BILL-TO 


VEHICLE/SHOP 


r Rates 







l._ „ _ .a I 'i 



-Products 

CDW PAI 


Drop Charge 


rAccount Details - 

mvtm 


Notes Taken i 1 


p Discounts and Specials - 
Add A Special 


rRate* 





ii Si I J — 



Figure 2 - Dates and Rates Screen - Middle Portion 
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'3 Enterprise^ ECARS Application - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 


Dates/Rates 


DRIVERS 


- Options - 


REFERRAL 


D AXES / RATE S 


BILL-TO 


VEHICLE/SHOP 


, r Products 

CDW PAI Drop Charge 


r~~r 



r Account Details- 


r Discounts and Specials- 


I Notes Taken : 1 


C Add A Special 


rRate- 



C Add A Discount 

L_J> 



Figure 3 - Dates and Rates Screen - Bottom Portion 
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m 
v% i 
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5 Enterprise^ ECARS Application - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 


Dates/Rates 


DRIVERS 


-Options- 


REFERRAL 


DATES /RATES 


10/11/2001 


BILL-TO 


VEHICLE/SHOP 


Notes Taken : 1 


- Pickup - 
Date: 


Time: 


110/11/2001 
Method: 


Location: 



rRate Source— 
Account Name 


rSelect-_ 
Rate Plan 
^Select- 


- Return - 
Date: 



Time: 


OliOO AM 


Location: 


0l!3Q AM 


71-' i, J > 

it 

^ 


02:00 AM 


02:30 AM 


03;0Q AM 


03;30 AM 



Rental Type 


r- Rata e: — ____________________ ___ — . 






1 L_J 



i 

L. : ■ r 




iff*' 

>* i* * < 


sift 


^5^^____i___^5rj «^ 


Figure 4 - Dates and Rates Screen - Pickup Time select box 
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Driver summary i 
Driver summary 2 


I 


Referral sum 1 
Referral sum 2 

3 

Dates summary 1 
Dates summary 2 


BILL-TO 


Bill-To summary 1 
Bill-To summary 2 


VEHICLE/SHOP 


Vehicle/Shop 1 
Vehicle/Shop 2 

Motes summary 1 
Notes summary 2 


i 

s 

t : 

i 

: 


Account Name 


Account Number 


-Select- 


Rental Type 


Rate Plan 


Car Class 


- Select - 


Rates Table 


Class 

Rate iyiil< 

? age 


Mileage 


$>&^ 

''Cv 

ileage 



CCAR 

9.99 

250 

29.99 

500 

99.99 

2500 

2.99 

0,25 

ECAR 

15.99 

250 

34.99 

500 

109.99 

2500 

3.99 

0,25 

FCAR 

20.99 

250 

39.99 

500 

209.99 

2500 

4.99 

0.25 

SCAR 

25.99 

250 

44.99 

500 

249.99 

2500 

5.99 

0.25 

PCAR 

30.99 

250 

49.99 

500 

309.99 

2500 

6.99 

0.25 

LCAR 

35,99 

250 

54.99 

500 

409.99 

2500 

7.99 

^,25 

XCAR 

40.99 

250 

110,99 

500 

509.99 

2500 

8.99 

0.25 


rge 


nuC! Li\ ib i iui i iuei"" £" 



'I 


- ! 


Tkt - 234567 Cbk ~ 363221 


Figure 5 - Dates and Rates Screen - Rate plan pop-up box 
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'5 fta+cff New - Microsoft In+enne*r Explorer provided by Enterprise ften+-a-Car 



DRIVERS 


Drjyer summary 1 
Driver summary 2 


REFERRAL 


Referral sum 1 
Referral sum 2 


DATES/RATES 


Dates summary 1 
Dates summary 2 


BILL-TO 


Bill -To summary 1 
Bill-To summary 2 


VEHICLE/SHOP 


Vehicle/Shop 1 
Vehicle/Shop 2 

Notes summary 1 
Notes summary 2 


Rates/Dates 


-Account Details — 
Hot Line number 1 
Hot Line number 2 


Here is some SI tent 

Here is some more SI text 

And another line, 

And one more for good measure. 


Car Preference 
Fuel Description 
Taa Exempt ind 
Auth required ind 
Claim number required ind 
Man dollar per day amount 


NO LUXURV CARS 
NO DIESEL 
TXEX123 

CALL (636) 467491? FOR AUTH 
CALL (636) 467491? FOR AUTH 


29,99 NO EXCEPTIONS 



1\ 

rv i 

it* 

i 

- ^ 



Tkt - 234567 


Cbk - 363221 


Figure 6 - Dates and Rates Screen - More Account Details pop-up box 
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3a: s> 
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W 
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'5 Rates blew - Microsoft Interne* Explorer provided by Enterprise Rent-a -Car 



I Driver summary 1 
Driver summary 2 


REFERRAL 


Referral sum 1 
Referral sum 2 


DATES /RATES 


Dates summary 1 
Dates summary 2 


8ILL-T0 


BiSI-To summary 1 
Bill-To summary 2 


VEHICLE/SHOP 


Vehicle/Shop 1 
Vehicle/Shop 2 

Notes summary 1 
Notes summary 2 


Rates/Dates 


rRate Source— 
Account Name 


Account Number 


[-Select- 


Accounts L IV ; : , > ; «V A- 


Account Name 


Rental Type 


A Collector's 
Rookstore** 


GE1658 Corporate 0101 6275 Delmar St Louis MO 63130 (314)721-6127 ™ 


A.f.j. Remodeling 
Co** 


3E1225 Corporate 0102 


312 Oak Pk. Wiidvood 
Village Dr, 


MO 63040 (636)458-1552 


Accent Lincoln- 


mercury'''* 


129498 Dealership 0103 


9700 St Louis 

Manchester 

Rd 


MO 63119 (314) 968-5300 v; 


Advantage 
Decorating** 


GE0853 Corporate 0104 


1601 North St Louis 
7th St 


MO 63102 (314)436-1419 

-Si 


African Amer. Rite Of GE1538 Corporate 0105 
Passage** 


325 St, Louis 

Debaliyiere 


MO 63112 (314)361- 


Ahzad Booostan** <3E0S3Q Corporate 0106 7743 Arthur St. Louis MO 63117 (314)645- 


Aiq-cs" 


GE023S Corporate 0107 


120 S St Louis 

Central, Ste 

300 


MO 63105 (000)000- 




. Tkt - 234567 Cbk - 363221 


>1 


Figure 7 - Dates and Rates Screen - Account Name Drop Down List 
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-3 Rates New* - Microsoft- Internet? Explorer provided by Enterprise Rent-a-Car 



\ 



DRIVERS 


Driver summary 1 
Driver summary 2 


REFERRAL 


Referral sum 1 
Referral sum 2 


Dates summary 1 
Dates summary 2 

Bill-To summary 1 
Bill-To summary 2 


Vehicle/Shop 1 
Vehicle/Shop 2 

Notes summary 1 
Notes summary 2 


Rates/Dates 


-Account Details 



■d 
<.\j 


31 Tkt - 234567 Cbk - 363221 


Figure 8 - Dates and Rates Screen - VLF Pop Up Box 


3- Reservation Number 

3.1 Behavior 

This area shows the unique reservation number that has been assigned to the newlv created 
reservation. The reservation number is 6 alphanumeric charac ters long. If another reservation is 
o pen, its reservation number will be displayed in this ar ea as well. The user will have the ability 
to have up to 3 reservations open at a time. A hyperlink will be available on the reservation 
numbers of the reservations that are NOT cu rrently being displayed. For the reservation that is 
currently displayed, the reserva tion number w ill not have a hyperlink available. This is to allow 
the user to navigate between the open reservations. 

3.2 Validation 

None identified at this time. 

3.3 Business E xceptions 

If the user tries to open a 4th reservation, the system will display a message. See the error 
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message supplemental spec for exact text. 

3.4 System Exceptions 

None identified at this time. 


4. Pickup Grou p/Branch Area 

4.1 Behavior 

This area is a display oniv field showing t he group/bra nch currentl y selected as the Pickup group/branch. 
It is formatted with the legacy Group number, the le gacy Branch number , a space, a dash, another space 
and the People Soft description of the Branch. 

4.2 Validation 

None identified at this time. 

4.3 Business Exceptions 

None identified at this time. 

4.4 System Exceptions 

None identified at this time. 


5. Pick Up Date Area * 
5.1 Behavior 

This area will be a numeric field. It will not be formatted for presentation purposes. 
The user may enter delineating characters, but these will be stripped out before searching the database to 
find an exact date match. There shoul d be a calendar function available which would allow the user to 
select a date from a calendar icon, or similar feature, instead of enteri ng a value. Tf the user selects a date 
from the calendar icons, it will be displayed in the date area format ted appropriately bv the locale. ( As 
determined for all locale sp ecific formatting.) 


5.2 Validation 

It will be a valid month, day an d year combination. If the date is not valid, the system will display a 
message. See the error mess age supplemental spec for exact text. 

5.3 Business Exceptions 

If the user does not enter a date, then for the purpose of quoting a rate this should default to the 
current date, but do not s ave the current date in the database. 

Pick-up date cannot be prior to the current date. If it is. display message to the user. Please see 
error message s up plemental spec for exact text. 

5.4 System Exceptions 

If not a valid month, dav and vear combination, the normal date in error message should be displayed. See 
the error message supplemental spe c for exact text. 

6. Pick Up Time Area 
6.1 Behavior 

The pick-up time area will be disabled until there is and entry into the nick-up date area. 
In Inr.ales where time is s hown by AM PM designation: 

This is an alphan umeric area. A valid entry to this area is a minimum of Hour Minute Minute and 
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AM/PM designation, and a maximum of Hour Hour Minute Minut e AM/PM designation. i.e. 945A. 
wouid designate 9:45 in the morning. A leading zero m av precede the hour, but is not reguired 
and will be removed before saving to the database. T he minutes must be two numeric values. 
The AM/PM designation of "A" or "P" m ust also be i ndicated. The user mav enter delineating 
characters, but these wiii be removed be fore saving to the database. 

in locales where time is shown by 24 hour designation: 

This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute, and 
a maximum of Hour Hou r Minute Mi nute, i.e. 945 would designate 9:45 in t he morning. 1425 
would designate 2:25 in the afternoon. A leading zero mav precede the ho ur, but is not reouired 
and will be removed before saving to the database. The minutes must be t wo numeric values. 
The user mav enter delineati ng characters, but these will be removed before saving to the 


6.2 Validation 

In locales where time Is s hown by AM PM designation: 

Time increments c an range from 1200A to 115QA and from 1 20QP until 1 159P. If an entry is not 
within these two ranges display a message to the user. Please see the error message 
supplemental spec for exact text of message. 

in locales where time is shown by 24 hour designation: 

Time increments can range from 0000 to 2400. if an entry is not w ithin this range display a 
message to the user. See the error message sup plemental spec for exactftext 

6.3 Business Ex ceptions 

If no time is entered or selected this should he defaulted t o the current time for the purpose of quoting a 
rate, but not s aved to the d atabase. 

if the pick-up time is outside of the branch's operating hours, displ ay a message tp the user. See 
Error Message Sup plementa l spec for exact text 

The pick-up time area will be disabled until th ere is and entry into the pick-up date area. 

6.4 System Exceptions 

None identified at this time. 


7. Pick U p Tim e Drop Down 
7.1 Behavior 

The pick-up time dropdown will he disabled until there is and entry into the Pick-up date area. 

This drop down icon will display a multi-colum n combination box. It will display the time in 30 
minute increments and the associated number of reservations, When selected, this should be 
positioned to 7:00 A.M. in the morning. 


7.2 Validation 

None identified at this time. 

7.3 Business Exceptions 

Tf no time is entered or selected 


ant time for th e purpose of quoting a 
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rate, but not saved to the database. 


The pick-up t ime area will be disa bled until there is and entry into the Pick-up date area. 

If the pick-up time is outside of the branch's operating hours, display a message to the user. See 
the error message supplemental spec for exact text. 

7.4 System Exceptions 

None identified at this time. 


8. Pick Up Method Drop Down 

8.1 Behavior 

This will be a drop down are populated with the following values on the left. The right si de is for 

information only. 

Blank 

CWC- Customer Will Call 
DEL - Delivery 

DEL/R - Delivery with Rideback 
P/UP - Pick Up 
W/IN-Walk In 

8.2 Validation 

Any one of the val ues is a valid selection, 

8.3 Business Exceptions 

None identified at this time. 

8.4 System Exceptions 

None identified at this time. 

9. Pick Up Location Area 

9.1 Behavior 

This is a free form alphanumeric area. 

9.2 Validation 

None identified at this time. 

9.3 Business Exceptions 

None identified at this time. 

9.4 System Exceptions 

None identified at this time. 

10. Pick Up Location Directions Button 

10.1 Behavior 

ilectino this button will display a free form alphanumeric oop-up box. The user mav enter 


information and if the OK button is selected the system will save the information and close the 


pop-up box. If the user selects the cancel button, the p o p-up box will be closed without anv 
changes saved. The user may also "click" outside the pop-up box area, which will close the box 
without saving anv chanc 
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10.2 Validation 

None identified at this time. 

10.3 Business Exceptions 

None identified at this time. 

10.4 System Exceptions 

None identified at this time. 


11. Return 


11.1 Behavior 

This area is a display only field showing the group/branch currently selected as the Return group/branch. 
It is formatt ed with the l egacy Gro up number the legacy B ranch nu mber, a space, a dash, another space 
and the PeopleSoft description of the Branch. 

11.2 Validation 

None identified at this time. 

11.3 Business Exceptions 

None identified at this time. 

11.4 System Exceptions * 

None identified at this time. 


12. Return Date Area 

12.1 Behavior 

This area will be a numeric field. It will not be formatted for presentation purposes. 
The user mav enter delineating characters, but these will be stripped out before searching the database to 
find an exact date match. There should be a calendar function available which would allow the user to 
select a date from a calendar icon, or similar feature, instead of entering a value. Tf the user selects a date 
from the calendar icons, it will be displayed in the date area formatted appropriately b y t he Iocale t (As 
determined fo r all locale specific form atting) 

12.2 Validation 

It will be a valid month, day an d year combination. See the error message supplemental spec for_exacj 


text 


12.3 



tf the user does not enter a date, then for the purpose of quoting a rate this should default to one 
calendar dav after the pick-up date, but will not be saved to the database. 

The return date cannot be before the pick-up date. If it is. display message to the user. See the 
error message supplemen tal spec for the exact text. 

12.4 System Exceptions 

If not a valid month, day and year combination, the normal date in error message should be displayed. See 
the error message supplemental spec for exact text. 
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13. Return Time Area 

13.1 Behavior 

The return time area will be disabled un til there is a nd entry into the return date area. 
In locales Where time fe shown by A M PM designation: 

This is an alphanumeric area. A valid entr y to this area is a minimum of Hour Minute Minute and 
AM/PM designation, and a maximum of Hour Hour Minute Minute AM/PM designation. i.e. 945A. 
would designate 9:45 in the morning. A leading zero may pr ecede the hour, but is not required 
and will be removed before saving to the database. The minutes must be two numeric values. 
The AM/PM designation of "A" or "P" must also be indicated. The user mav enter delineating 
characters, but these will be removed before saving to the database. 

In locales where time is shown by 24 hour designation: 

This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute, and 
a maximum of Hour Hour Minute Minute T i.e. 945 would designate 9:45 in the m orning. 1425 
j«% would designate 2:25 in the afternoon. A leading zero mav precede the hour, but is not required 

S and will be re moved bef ore saving to the database . The minu tes must be two numeric values. 

i The user mav enter delineating char acters, but these will be removed be fore saving to the 

database. 


m 

Pi 


13.2 Validation 


In locales where time is shown by AM PM designation: 
Time increments can range from 1200A to 11 59 A and from 12QQP until 1159P. If an entry is 
M not within these two ran ges display a message to the user. See the error message 

i]| supplemental spec for exact text. 


In locales where time is Show n bv 24 hour designation: 

Time increments can range from 0000 to 2400. If an entry is not within this ra nge displays 

message to the user, See the error message supplemental spec for exact text. 

13.3 Business Exceptions 

If no time is entered or selected this should be defaulted to the same time as the pick-up time for the 
purpose of quoting a rate bu t should not be saved to th e database. 

The return time area will be disabled until there is and entry into the return date area. 

13.4 System Exceptions 

None identified at this time. 

14. Return Time Drop Down 

14.1 Behavior 

■ ■ i ■ ■■ ' 

The return time dropdown will be disabled u ntil there is and entry into the return date area. 

This drop down i con will dis play the time in 15-minute in crements. When selected, it should be 
positioned to the same time as the Dick up time. 
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14.2 Validation 

None identified at this time. 

14.3 Business Exceptions 

If no tim e is entere d or selecte d this sho uld be defaulted to the same time as the pic k-up time for the 
purpose of quoting a rate, but not saved to the database. 

The return tim e dropdown will be disabled until there is and entry into the return date area. 

14.4 System Exceptions 

None identified at this time. 

15. Return Method Drop Down 

15.1 Behavior 

This will be a drop down list of the followi ng values. 
Blank 
j., Branch 


IIS ST 


Drop 


Si Ride Back 

IM 


W Nlnte: In the U K the value of APU (Automa tic Pink Up) will replace Drop. 

VI 15.2 Validation * 


X „ s 


Anv one of the values is a valid sel ection. 
f. 15.3 Business Exceptions 

| IBS 

■» i None identified at this time, 

III 15.4 System Exceptions 

M ' None identified at this time. 

U 16. Return Loca tion Area 

16.1 Behavior 

This is a free form alphanumeric area. 

16.2 Validation 

None identified at this time, 

16.3 Business Exceptions 

None identified at this time. 

16.4 System Exceptions 

None identified at this time, 

17. Account N ame Drop Down 
17.1 Behavior 

This area will be a drop down list of the Branch's short list, for No rth America For everywhere 
else it will be the Group's Account list. If there are a ny of the following associated with the 
particular reservation, they will appear at the too o r beginning of the list in the folk 

1) Anv Bill-To Accounts 

2) Anv Referral Accounts - Excluding employees as a referral source. 
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is* 


; a 


lira? 


3) Anv Shoo Accounts 

The Information displayed about an Account will be in the following order: 

1) Account Name 

2) Account Number 

3) Rental Type 

4) Owning Grou p/Branch 

5) Address 

6) g& 

7) State 

8) m 

9) Telephone 

The Account Name in the display area will have a hyper-link which, when selected, will populate 
the Account Name. Account Number. Rental Type and Rate Plan areas on the Dates and Rates 


17.2 Validation 

None identified at this time. 

17.3 Business Exceptions * 

If Account name or number is selected and the following account types are deter mined, then other areas will be 
ted to the values shown. 


Account Tvne 

Insura nce 


Bodvshop 


Rental Tvne 


Insurance. 


Bodvshop 


Billing Cvcle 
Calendar Day 


Calendar Dav 


Corporate 

ueaiersmp 

Corporate 

zq nour 
24 hour 

Government 

Coroorate 

24 hour 

Fleet 

Corporate 

24 hour 

Other 

Other 

24 hour. 


17.4 System Exceptions 

None identified at this time. 

18. Account Number Area 

18.1 Behavior 

This area will all ow entry of alphanumeric values. When there is a match, the system will populate 
the Account Name . Account Number. Rental Type and Rate Plan areas on the Dates and Rates 
panel. 


18.2 Validation 

None identified at this time. 
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18.3 Business Exceptions 

None identified at this time. 

18.4 System Exceptions 

None identified at this time. 

19. Search Button 

19.1 Behavior 

Selecting this button will display the account search panel. See Referral Source Supplementary 
Specification for details. 

19.2 Validation 

None identified at this time. 

li, 19.3 Business Exceptions 

None identified at this time. 

19.4 System Exceptions 

None identified at this time. 

20. Rental T ype Drop Down * 


o 


20.1 Behavior 

This area will be a drop down list of R ental types. 

The domain values in the database are: 

llJ • Body Shop 

01 • Corporate 

P • Dealership 

|«A • Insurance 

• Other 

• Retail 


111 


See list in account name area for defaults, based on account. 

It is also possible to leave the Account Name and Account N umber areas blank and to select a Rental Type 
value from the drop down list and select the Get Rates Button. If this is performed the system will get the 
Group/Branch default rates for the rental type sel ected and display this in the pnp-im rate table display. 

20.2 Validation 

Anv value selected is valid. 

20.3 Business Exceptions 

None identified at this time. 


20.4 System Exceptions 

None identified at this time. 
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21. Rate Plan Drop Down 

21.1 Behavior 

This area will be populated wh en an Account Name. Account Number o r a Rental Type has been 


If there are multiple plans associated with an Account, it will list all of the rate plan s associated 
with that Account, and the user must choose one. When there are multiple rate plans, the value 
"select" will appear in area so the user knows that there are multiple rate plans and sele ction of a 
single one is required. 

If there is only a single rate plan associated with an d Account then the rate plan pop-up box will 
appear show all of the car classes and rates associated with that account. 


21.2 Validation 

None identified at this time. 

q 21.3 Business Exceptions 

Q Tf no rate plans are associated with an Account then a message is displayed. See die error message 

m supplement al snec for exact text. 

^ 21.4 System Exceptions 

J'jj None identified at this time. t 

"is 

W 22. Car Class Drop Down 

L 22.1 Behavior 

jlj This area will be a drop down list that also allows entry of alphanumeric values. The drop down 

flj list will be co mprised of the most commo nly used car classes, for North America. Europe will 

■q\ show all of the car classes associated with that coun try. The entrv of alphanumeric values will be 

Pi edited aaainst a larger more comprehen sive car class list. 

Drop down list values for North America. 
.Class and Type 


ECAR 

SCAR 

FCAR 

PCAR 

LCAR 

MVAR 

XFAR 

XPAR 

XXAR 

XVAR 


Drop down list values for Ireland. 

Clans and Tvne Description ( Information Only) 
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A 

MINI 

B 

SUPERMINI 

C 

LOWER MEDIUM 1.3/1.4 

D 

LOWER MEDIUM 1 . 6 

E 

UPPER MEDIUM 1.8 

F 

UPPER MEDIUM 2 . 0 

G 

EXECUTIVE 

MMPV 

MINI MPV 

MPV 

MPV 

SMPREM 

SMALL PREMIUM 

LGPREM 

LARGE PREMIUM 

EXP REM 

EXECUTIVE PREMIUM 

SPEC 

SPECIALITY 

CEST 

LOWER MEDIUM 1.3/1.4 ESTATE 

DEST 

LOWER MEDIUM 1.6 ESTATE 

EEST 

UPPER MEDIUM 1.8 ESTATE 

FEST 

UPPER MEDIUM 2.0 ESTATE 

GEST 

EXECUTIVE ESTATE 

SPREE 

SMALL PREMIUM ESTATE 

LPREE 

LARGE PREMIUM ESTATE 

SMCV 

SMALL COMMERCIAL VAN 

LGCV2 

LG COMM VAN -LOW /MED ROOF/SWB 

LGCV3 

LG COMM VAN-HIGH ROOF/LWB 

MBUS10 

MINIBUS-10 SEAT 

MBUS12 

MINIBUS-12 SEAT 

MBUS15 

MINIBUS- 15 SEAT 

MBUS17 

MINIBUS-17 SEAT 

AA 

MINI-AUTO GEARBOX 

BA 

SUPERMINI -AUTO GEARBOX 


LOWER MEDIUM 1.3/1. 4 -AUTO 

DA 

LOWER MEDIUM 1 . 6-AUTO 

Class and Tvne 

Description ^Information OnlV> 

EA 

UPPER MEDIUM 1.8-AUTO 

FA 

UPPER MEDIUM 2 . 0-AUTO 

GA 

EXECUTIVE- AUTO GEARBOX 

MMPVA 

MINI MPV-AUTO GEARBOX 

MPVA 

MPV-AUTO GEARBOX 

SPREA 

SMALL PREMIUM- AUTO GEARBOX 

LGPREA 

LARGE PREMIUM- AUTO GEARBOX 

EX PRE A 

EXEC PREMIUM-AUTO GEARBOX 

SPECA 

SPECIALTY-AUTO GEARBOX 

CESTA 

LOWER MEDIUM 1.3/1/4 EST-AUTO 

DESTA 

LOWER MEDIUM 1.6 ESTATE-AUTO 

EESTA 

UPPER MEDIUM 1.8 EST-AUTO 

FESTA 

UPPER MEDIUM 2.0 ESTATE-AUTO 

GESTA 

EXECUTIVE ESTATE-AUTO 

SPREEA 

SMALL PREMIUM ESTATE-AUTO 

LPREEA 

LARGE PREMIUM ESTATE-AUTO 
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Dron down list values for U.K. 

Class and Tvne Dcscrintion (Information Only) 


a - 


A 


B 


C 


D 


MMPV 


MPV 


SMPREM 


LGPREM 


EXPREM 


SPEC 


CEST 


MINI 


SUPERMINI 


LOWER MEDIUM 1,3/1.4 


LOWER MEDIUM 1.6 


UPPER MEDIUM 1.8 


UPPER MEDIUM 2.0 


EXECUTIVE 


MINI MPV 
MPV 


SMALL PREMIUM 


LARGE PREMIUM 


EXECUTIVE PREMIUM 


SPECIALITY 


LOWER MEDIUM 1.3/1.4 ESTATE 


"i 

w 


III 


PEST 


GEST 


SPREE 


LOWER MEDIUM 1 . 6 ESTATE 



EEST 

UPPER MEDIUM 

1 

.8 

ESTATE 

y 

FEST 

UPPER MEDIUM 

2 

.0 

ESTATE 


LPREE 


SMCV 


LGCV2 


LGCV3 


MBUS10 


EXECUTIVE ESTATE 


SMALL PREMIUM ESTATE 


LARGE PREMIUM ESTATE 


SMALL COMMERCIAL VAN 


LG COMM VAN-LQW/MED ROOF/SWB 


LG COMM VAN-HIGH ROOF/LWB 


MINIBUS-10 SEAT 


3 s 


Description (Information On\\) 


MBUS12 


AA 


BA 


SPREA 


LGPREA 


EXPREA 


SPECA 


CESTA 


MINIBUS-12 SEAT 


MBUS15 

MINIBUS-15 

SEAT 

MBUS17 

MINIBUS-17 

SEAT 


MINI -AUTO GEARBOX 


SUPERMINI -AUTO GEARBOX 


CA 

LOWER MEDIUM 1.3/1.4-AUTO 

DA 

LOWER MEDIUM 1 . 6-AUTO 

EA 

UPPER MEDIUM 1.8-AUTO 

FA 

UPPER MEDIUM 2 . 0-AUTO 

GA 

EXECUTIVE-AUTO GEARBOX 

MMPVA 

MINI MPV- AUTO GEARBOX 

MPVA 

MPV-AUTO GEARBOX 


SMALL PREMIUM-AUTO GEARBOX 
LARGE PREMIUM-AUTO GEARBOX 


EXEC PREMIUM- AUTO GEARBOX 


SPECIALTY-AUTO GEARBOX 


EST-AUTO 
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DESTA 
EESTA 


LOWER MEDIUM 1.6 ESTATE -AUTO 
UPPER MEDIUM 1,8 EST-AUTO 


EKOMA 


FKOMA 


FESTA 

UPPER MEDIUM 2.0 ESTATE-AUTO 

GESTA 

EXECUTIVE ESTATE-AUTO 

SPREEA 

SMALL PREMIUM ESTATE -AUTO 

LPREEA 

LARGE PREMIUM ESTATE-AUTO 

Drop down list values for Germany 

Class and Tvpe 

Description (information Onlv) 

A 

MTNT 

B 

SUPERMINI 

C 

LOWER MEDIUM 

n 

PREM LOWER MED 

E 

UPPER MEDIUM 

i. 

PREM UPPER MED 

G 

PREMIUM EXECUTIVE 

H 

LUXURY 


T.OWPR MFD KDMRT 

P"pff}M 

HPPPP MPTiTTTM fCOMRT 
UirirCjiv I v JIjUXUL v 1 x\WL v JD± 


PPFM Tlpprp MVD KOMPT 


PRPMTT1M PYPPTTTTVP PfOMPT 


L V J JL IN X riU i ULYiri 1 1 1\ 

BA 

OUld I\L w J.X IN X nUi Wrln ± X i\ 


T HKTPP MFHTTIM- RnTHMftTTK" 
JjwvVIlirs. L IHjU ± U1J rlU 1 ^i v ±rl 1 X I\ 




nppFR MFHTTTM-anTOMATTK" 

1 'mn^ am/I r 1 'vmA 

uescnpnon unioriuauon vniyj 

FA 

PREM UPPER MED-AUTOMATIK 

GA 

PREMIUM EXECUT I VE -AUTOMAT I K 

HA 

LUXURY- AUTOMAT IK 

MMPV 

MINI MINI VAN 

MPV 

MINIVAN 

SPEC 

CABRIO SPECIALTY 

SMTR 

SMALL TRANSPORTER 

LGTR1 

LARGE TRANS PORTERS -SWB 

LGTR2 

LG TRANSPORTERS-HI ROOF/LWB 

4WD 

4 WD SPORT UTILITY 

SM4W 

SMALL 4 WD SPORT UTILITY 

MMPVA 

MINI MINI VAN-AUTOMAT IK 

MPVA 

MINI VAN- AUTOMAT I K 

4WDA 

4 WD SPORT U T I L I TY- AUTOMAT I K 

SM4WA 

SMALL 4 WD SPORT UTIL- AUTOMAT IK 

SPECA 

CABRIO SPECIALTY -AUTOMAT IK 

CKOMA 

LOWER MED KOMB I -AUTOMAT IK 


UPPER MEDIUM KOMB I -AUTOMAT IK 


PREM UPPER MED KOMBI -AUTOMAT IK 
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PREM EXEC KOMB I -AUTOMAT IK 



22.2 Validation 

None identified at this time. 

22.3 Business Exceptions 

If the values entered are not one of the ones li sted below, a message is displayed. See the error message 
supplementa l spec for exact text. 

Car Class Edit List of Values for North America. 


s s ; 


Class and Type 
MCAR 


MDAR 
ui MXAR 
h MSAR 
my MTAR 
m MWAR 


m 

4 S3 9, 



ECAR 
EBAR 
: EDAR 
I s * EXAR 
pi ESAR 

"U ETAR 
EWAR 
EVAR 
EFAR 
EPAR 
CCAR 


CDAR 
CXAR 
CSAR 
CTAR 


CVAR 

CFAR 

CPAR 

ICAR 

IBAR 

IDAR 

IXAR 


TTAR 
TWAR 


IFAR 
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SCAR 
SEAR 
SPAR 


SSAR 

STAR 

SWAR 

SVAR 

SFAR 

SPAR 

FCAR 

FBAR 

FDAR 



FTAR 
FWAR 


IV FFAR 

m em 

H PCAR 
PBAR 
PDAR 
PXAR 

Hi ESAS 
I,, PTAR 

|J* PWAR 

•ill 


PVAR 
PFAR 


H PEAR 


LCAR 
LBAR 
LPAR 



LTAR 

LWAR 

I-VAR 


LEAR 
XCAR 
XBAR 



XTAR 
XWAR 
XVAR 
XFAR 
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ASS 

i y 

\#4 


! W 


22.4 System Exceptions 

None identified at this time. 

23. Get Rates Button 
23.1 Behavior 


tion of this button will hav e the system execute a search for rate plans a ssociated with the 
entered. No rate tables will disp lay for a rate search until the Get Rates Button is p ressed. 

23.2 Validation 

None identified at this time. 

23.3 Business E xceptions 

selects this button without one of these a me ssage is displayed. See the error message supplemental spec 


U 23.4 System Exceptions 

None identified at this time. 

24. Rate Plan - Pop-Up Display Area 

5 24.1 Behavior t 

jj This is a pop-up window that will display the rates of a rate plan associated with an Account. 

„ Information displayed is: 

Rate pop-up box coli 
• Car Class 


Daily - Rate and Mileage 


m # Weekly - Rate and Mileage 

!** • Monthly -Ra te and Mil 


Hourly - Rate 
Mileage Charge 

will have a h yper-link which will allow the user to select the rate thev want. This will then 
populate the rates display area on the D ates and Rates panel. 


Validation 

None identified at this time. 

Business Exceptions 

If an Account has more than one r ate plan associated with it. then this information cannot be 
displayed until the Ra te Plan area has a value. 

If an Account has a single rate pla n associated with it. then this information is display ed after the 
Account Name is selected or an Account Number is entered and the Get Rates Button is 


If an Account has a single rate plan and ther e is a value in the Car Class area, and that car class 
is in the rate plan and the Get Rates Button is peressed. then the rates display area of the Dates 
and Rates panel is populated with the app ropriate information and the rate plan oop-up window is 
NOT displayed. 
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If an Account has multiple rate plans and t here is a value in the Car Class area, and there is not a 
value in Rate Plan area, a message should display t o the user. See the error message 
supplemental sp ec for exact text. 

If an Account has a multiple rate p l ans, and there is a value in the Rate Plan are a and there is a 
value in the Car Class ar ea, and that car class is in the rate plan, then the rates display area of 
the Dates and Rates panel is populated with the appropriate information and the rate plan pop-up 
window is NOT disp layed. 

If an Account has a single rate plans, a nd there is a value in the Car Class area, but that car class 
is not in the rate plan, then a message is displayed. See the e rror message supplemental spec 
forgxact text. 

JLan Account has a multiple rate p lans, and th ere is a value in the Ra te Plan ar ea and there is a 
value in the Car Class area, but that car class is not in the rate plan, then a mess age is displayed 
See the error message supplemental s pec for exacLtext 

24.4 System Exceptions 

None identified at this time 

25. Rate Plan - Display Area 

25.1 Behavior 

This is a displa y area that allows the user to manually enter rates or can be populated by the 
system once the user has determined a set of rates to be used for the reservation. 

The fields available to the user are: 

• Daily Rate 

• Daily Mileage 

• Weekly Rate 

• Weekly Mileage 

• Monthly Rate 

• Monthly Mileage 

• Hourly Rate 

• Mileage Charge 

All of the information presented has the ability to be edited or changed. 

There is an in teraction between the Mileage Char ge and the No Charge Check Box. If the No Charge 
Check Box is selecte d, then the Mileag e Charge is set to zero and the area disa bled. Unselecting the No 
Charge Check B ox will enable the Mile Ch arge area for e ntering values. 

25.2 Validation 

None identified at this time. 

25.3 Business Exceptions 

Negative values may not be entered. If atte mpted, d isplay mess age. See the error m essage s upplementa l 
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spec for exact text 

25.4 System Exceptions 

None identified at this time 

26. Billing Cvcle Drop Down 
26.1 Behavior 

This area will initially default to the billing cycle associated with the Account and Rate Plan 
selected. It mav be changed to anther value. 

down domain values are Blank, 24 Hour and Calendar Day. 


26.2 Validation 

None identified at this time. 

26.3 Business Exceptions 

s . See list in account name area for defaults, based on account. If the user or system selects ^Calendar dav v 

tl as a value in this field, the hourly rate field must be disabled. If the user or system changes the value to 

jj[ either blank or 24 hour, the hourly rate field must be enabled again. 

pj 26.4 System Exceptions 

0] None identified at this time 


27. Vehicle Preferences Area 


27.1 Behavior 

jj\ This area will allow entry of alphanumeric values. 

|1J 27.2 Validation 

None identified at this time. 


27.2 Business Exceptions 

None identified at this time 


27.4 System Exceptions 

None identified at this time 

28. Products - CDW Area 

28.1 Behavior 

— II II I.I Illl I II 

This area will allow the user to enter a currency value for CDW. If the user has selected an 
account, and the account has values for CDW. thes e should b e populated i n the area as well. 
The user can change or remove the values at anytime. 

28.2 Validation 

None identified at this time. 


28.3 Business Exceptions 

Negative values may not be enter 
s pec for exact text. 


display message.- See the error message supplemental 


28.4 System Exceptions 

None identified at this time 
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29. Products - PA1 Area 

29.1 Behavior 

This area will allow the user to enter a currency value for PAL If the use r has selected an 
account, and the account has a value for PAl. this value should be po pulated into th e area. If a 
value already exists, the new value will overwrite the existing value. The user can change or 
remove the value at anytime. 

29.2 Validation 

None identified at this time. 

29.3 Business Exceptions 

Negative values may not be entered. If attempted, dis play messag e. See the error message s upplemental 
spec for exact text. 

29.4 System Exceptions 

|«» None identified at this time 

M 

m 3°- Products - Drop Charge area 

|| 30.1 Behavior 

H The area will allow the user to enter a drop charge for the reservation. It may be cjianqed for edited. 

h] 30.2 Validation 

« None identified at this time. 

£*, 30.3 Business E xceptions 

}jj A numeric value greater than or equal to zero must be entered. 

ill 30.4 System Exceptions 

\*4 None identified at this time. 

s a 
ansa; 

31. Account De tails Area 

31.1 Behavior 

This area will display the two "ho t lines" from legac y Special Instructions associated with a rate 
plan for an Account. It is a display only area. 

31.2 Validation 

None identified at this time. 

31.3 Business Exceptions 

None identified at this time. 


31.4 System Exceptions 

None identified at this time. 

32. Account Details "More" Button 

32.1 Behavior 

Selection of this button will display a pop-up box which will display all of the SI de 
rate plan for an Account. 
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32.2 Validation 

None identified at this time. 

32.3 Business Exceptions 

None identified at this time. 

32.4 System Exceptions 

None identified at this time. 

33. VLF Button 

33.1 Behavior 

Selection of this button will display a no p-up box which will disnlav all of the V ehicle License Fee 
information which must be given to a renter in certain states. 

33.2 Validation 

None identified at this time. 

33.3 Business Exceptions 

None identified at this time. 


a - 
|ss« 

Haas? 

M 

ill 

p 33.4 System Exceptions 


S J None identified at this time. 

34. Discount and Specials - Add a Sp ecial Check Box 


. t :: n 

I s * 34.1 Behavior 


" £ 7 

Selection of this check box will enable all of the "Special" inr 


m 34.2 Validation 


in 


None identified at this time. 

34.3 Business E xceptions 

In order to have a special, a billing cycle must be specified. If this is checked, and billing cvcie is blank. 
disnlav a message. See the error mess age supplemental spec for exact text 

34.4 System Exceptions 

None identified at this time. 

35- Special - Start Date Area 

35.1 Behavior 

This area will be a numeric field. It will not be formatted for presen tation purposes. 
The user may enter de lineating ; characters, but these will be stripped out before searching the database to 
find an exac t date match. There should be a ca lendar func tion available which would allow the user to 
select a date from a calendar icon, or similar feature, instead of entering a value. If the user selects a date 
from the calendar icons, it will be displayed in the date area formatted appropriately bv the locale. (As 
determined for all locale specific formatting.^ 

35.2 Validation 

It will be a vali d month, d ay and year combination. 
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35.3 Business Exceptions 

If there is a Pick-Up date ente red then the Special Start date cannot b e prior to the Pick-up date. 
If it is. display a message. See the e rror message supplement al spec for exact text. 


If there is no Pick-up date, then the Start d ate cannot be prior to the current date. If it is. disp lay a 
message. See the error message supplemental spec for exact text. 

All of date and time fields are required for a special If a Start date not entered, display a message. See the 
error message sup plemental spec for exact text. 

35.4 System Exceptions 

If not a valid month, dav and year combination, the normal date in error message should be displayed. See 
the error message supplemental spec for exact text, cu 


Special - Start Time Area 

Behavior 

Iha start time a rea will be disabled until there is and entry into the start date area. 
In locales Where time is shown bv AM PM designation: 

This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute and 
AM/PM designation, and a maximum of Hour Hour Minute M inute A M/PM designation. i.e. 945A. 
would designate 9:45 in t he morning. A leading z ero mav precede the hour r but is not required 
and will be removed before saving to the database. The minutes must be two nume ric values. 
The AM/PM designation of "A" or "P" m ust also be i ndicated. The user mav enter delineating 
m characters, but these will be removed before saving to the database. 

S3: 

g~ In locates where time is shown by 24 hour d esignation: 

~j This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute, and 

a maximum of Hour Hour Minute Minute, i.e. 945 would designate 9:45 in the morning. 1425 

**" would desig nate 2:25 in t he afternoo n. A leading zero mav precede the hour, but is not reouired 

and will be removed before saving to th e database. The minutes must be two numeric valum. 
The user mav enter delineating characters, but these will be removed before saving to the 
database. 


36.2 Validation 

lnJocales where time Is shown by AM pm designation: 

Time increments can range from 1200A to 1159A and from 120QP until 1159P. If an entry is 
not within these two ranges disoiav. Se e the error message supplemental spec for exact 

text 

In locales wher e time fe Sho wn by 24 hour designation: 

Time incre ments can range from 0000 to 2400. If an entr y is n ot within this range display a 
message to the user. See th e error message supplemental spec for exact text. 

36.3 Business E xceptions 

The start time area will be disabl ed until there is and entry into the start date area. 
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36.4 System Exceptions 

None identified at this time. 

37. Special - Start Time Drop Down 

37.1 Behavior 

The start time dropdown will be disabled until there is and entry into the start date area. 

This drop down icon will display the ti me in 15-minute increments. When selected, it should be 
positioned to the % hour increment immediately preceding the current time and format according 
to the locale's format. 

37.2 Validation 

None identified at this time. 

37.3 Business Exceptions 
U The start time dropdown will be disabled until there is and entry into t he start date area. 


r 

Q 37.4 System Exceptions 


hi 


None identified at this time. 
38. Special - End Date Area 


38.1 Behavior 

U This area will be a numeric field. It will not be formatted for presentation purposes. 

i y The user mav enter del ineating cha racters, but these will be stripped out before searching the d atabase to 

m find an exact date match. There should be a calendar function available which would allow the user to 

J ^ select a date from a calendar icon , or similar feature, ins tead of entering a value. If the user selects a date 

from the calendar icons, it will be displayed in the date area formatted appropriately ' 


ft determined for all locale specific formatting.^ 


38.2 Validation 

It will be a valid month, day and year combination. 

38.3 Business Exceptions 

Special End date cannot be prior to the Special Start date. I f it is. display a message. See the 
error messa ge supplemen tal spec for exact text. 

If there is a Return date then the Special En d date cannot be after the Return date. If it is. display 
a message. See the error message supplemental spec for exact text. 

If there is not a Return date, then Special End date mav be anv value eoual to or after Special 
Start date. 

All of date and time fields a re required fo r a special. If a Start date not entered, dis play a me ssage. See the 
error message supplemental spec for exact text. 
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38.4 System Exceptions 

If not a valid month, dav and year combination, the nor mal date in err or message should be displayed. See 
the error messag e supplemental spec for exact text. 

39. Special - End Time Area 
39.1 Behavior 

The end time area will be disabled until there is and entry into the end date area. 
In locates where time is shown by AM PM designation: 

This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute and 
AM/PM designation, and a maximum of Hour Hour Minute Minute AM/PM designation. i.e. 945A. 
would desig nate 9:45 in the morning . A leading zero mav precede the ho ur, but is not required 
and will be re moved b efore saving to the da tabase. The minutes must be tw o numeric values. 
The AM/PM designation of "A" or "P" must also be indicated. The user mav enter delineating 
characters, but these will be removed before saving to the database. 


P in locales where time i s shown b y 24 hour designation: 

O This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute, and 

Hi a maximum of Hour Hour Minute Minute, i.e . 945 would designate 9:45 in the morning. 1425 

IM would designate 2:25 in the afternoon. A leading zero mav precede the hour, but is not reouired 

and will be removed before saving to the database. The minutes must be two numeric values. 
The user mav enter delin eating characters, but these will be removed befdre saving to the 
database. 


1$$ 


39.2 Validation 

Iniocales Wher e time is shown bv AM PM designation: 

Time increments can range from 1200A to 11 59A and f rom 120QP until 1159P. If an entry is 
not within these two rang es display a message to the user. See the error message 
supplemental s pec for exact text. 

lpjQcales where time is shown by 24 ho ur designation: 

lime incremen ts can rang e from 0000 to 2400. If an entry Is not within this range display a 
message to the user. See the error message supplemental spec for exact text. 

39.3 Business Exceptions 

The end time area will be disabled until there is and entry into the end date area. 

39.4 System Exceptions 

None identified at this time. 

- End Time 


40.1 Behavior 


The end time dropdown will be disabled until there is and entr y into the end date area. 
This drop down icon will display the time in 15-minute increment s. When selected, it should be 
positioned t o the % hour increment im mediately preceding the current time and format according 
to the locale's format. 
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40.2 Validation 

None identified at this time. 

40.3 Business Exceptions 

The end time dropdown will be disabled until there is an d entry into the end date area. 

40.4 System Exceptions 

None identified at this time. 

41. Special - Rate Area 

41.1 Behavior 

This is a numeric area. 

41.2 Validation 

, . None identified at this time. 

Q 41.3 Business Exceptions 

W Negative values mav not be entered. If at tempted, display message. See the error message supplemental 

01 spec for exact text 

P] 

J"t 41.4 System Exceptions t 

i r. i None identified at this time 

! . 42. Special - Rate Type Drop Down 
llj 42.1 Behavior 

Hi This is a drop down list. The domain values are Per Dav Special and Package Special. 

y 42.2 Validation 

raw 

|4 None identified at this time. 

42.3 Business Exceptions 

None identified at this time. 

42.4 System Exceptions 

None identified at this time 

43, Special - Mileage Area 

43.1 Behavior 

This is a numeric are a. This area will be disabled if the No Charge check box is selected. If not selected the 
area is enabled. It should default to enabled. 

43.2 Validation 

None identified at this time. 

43.3 Business Exceptions 

Negative values mav not be entered. If attempted display message. See the error message supplemental 
spec for exact text. 

43.4 System Exceptions 

None identified at this time. 
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44. Special - Mileage No C harge Check Box 

44.1 Behavior 

If the No C harge Check Box is select ed, then the Milea ge area is set to zero and the 
Unselecting the No Charge Check Bo x will enable th e Mile area for entering values. 

44.2 Validation 

None identified at this time. 

44.3 Business Exceptions 

If there is unlimited mile in the n ormal rate th en special mileage has to he unlim ited. You can never have a 
special mileage charg e i f the normal rate is unlimited. If the user attempts to so this 
See the error messa ge supplemental sp ec for exact text. 

44.4 System Exceptions 

None identified at this time 

45. Discounts and Specials - Add a Di scount Check Box 

p 45.1 Behavior 

Selection of this check box will enable the "Discount %" input area. 

45.2 Validation 

hl\ None identified at this time. 

I 45.3 Business Exceptions 

None identified at this time. 

45.4 System Exceptions 

flj None identified at this time 

46. Discount - Discount P ercent Area 


o 


Hi 


"is 


hi 

5W 


m 
0 

P 46.1 Behavior 

This is a numeric area* Values sho uld be entered without any decimals Le» a value of 8 would men8%^a 
value of 20 would be 20%. 

46.2 Validation 

Values cannot contain decimals. 

46.3 Business E xceptions 

A discount cannot excee d the value of 50. If the user enters a valu e greater tha n 50. a message is displayed. 
See the error message supplemental spec for exact text, 

46.4 System Exceptions 

If a value is entered with decimals, a message is displayed. See the error message suppl emental spec for 
exact text. 

47. Security 

The user must have the appropriate securit y level to access these screens. The user is allowed to v iew or 


print anything. It is when thev attempt to edit a reservation that their security restrictions will be enforced, 
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48. Special - Excess Mileage Charge 

48.1 Behavior 

This is a numeric area. Values should be entered without any decimals i.e. a value of 8 would mean . 08 and a value 
of 20 would mean ,20. 

48.2 Validation 

Values cannot contain decimals . 

48.3 Business exceptions 

48.4 System Exceptions 

if a value is entered that co ntains decimals, the syste m will display a message to the user. See the error message 
supplemental spec for exact text. 
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Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the Driver Search screen. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 
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2. 


Driver Search 


a Driver Search - blank result set - Microsoft: internet Explorer providedj^i|je^^j^^| 


o x 


i 

Telephone 


DRIVERS 


river Search 


Driver summary 1 
Driver summary 2 


Last Name 


First Name 


REFERRAL 


Referral sum 1 
Referral sum 2 


DATES/RATES 


Dates summary 1 
Dates summary 2 


BILL-TO 


Bill-To summary 1 
Bill-To summary 2 


VEHICLE/SHOP 


Vehicle/Shop 1 
Vehicle/Shop 2 

Notes summary 1 
Notes summary 2 


i! - 

Drivers License Number 


Date of Birth 



Items 0 of 0 found 


Prev 1 Next 


Res - 411781 


Tkt - 234567 Cbk - 363221 


^ ; > ■ - ::- ~ rrr!* ; < 5 


I Locafc fr^ranet - ; <c * ^ * a ^ 


Figure 1 - Driver Search - No Display List 
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^3 Driv er Search - Microsoft Inte rnet Explorer provided by Enterprise Rent a Lnr 


Address] 


drivers J Driver Search 


Driver summary 1 
Driver summary 2 


Telephone 


Last Name 


a 


511 


Referral sum 1 
Referral sum 2 


DATES/RATES 


Dates summary 1 
Dates summary 2 

Bill-To summary 1 
Bill-To summary 2 


VEHICLE/SHOP 


Vehicle/Shop 1 
Vehicle/Shop 2 

Notes summary 1 
Notes summary 2 


Drivers License Number 


IC^ltiatSsrt^ 
First Name 


[- Options -jJlgg | jttj . 


Date of Birth 








Atteberry, James 

2002 Mateus ADt B, Maryland f444'l 444-4444 fHl 

11/20/1971 


Heights 

(314) 512-3479 (W) 

Bond, James 

Classified, Unknown 




P.oe, Jane 

123 West Main, Anywhere 


1/2/1943 

! Jets on, Georqe 

5 Spacely, Apt 4, Sprockets 2135474798 eKt45678(W) 

5417891234 (0) 


! Lobochecski,, Steve 

Mathews, Hike 

Puiols, Albert 






Items 1 - 10 of 10 found 


Prev 1 Next 


SI Tkt - 234567 Cbk - 363221 


Figure 2 - Driver Search - Result Display List 
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3 Driver Search - Address sorted ascending ^rasoftIi^^^tB0k^^^^^^^^t0i^^^^^^^^^^ 



Telephone 


drivers IDriver Search 


Driver summary 1 
Driver summary 2 


Last Name 


First Name 


3 ! 


PI 

n 


IP i 


REFERRAL 


Referral sum 1 
Referral sum 2 


DATES/RATES 


Dates summary 1 
Dates summary 2 


BILL-TO 


Bill-To summary 1 
Bill-To summary 2 


VEHICLE/SHOP 


Vehicle/Shop 1 
Vehicle/Shop 2 

Notes summary 1 
Notes summary 2 


r 


Drivers License Number 


Date of Birth 



123 West Main, Anywhere 


1/2/1943 — 1 


Atteberry, James 


2002 Mateus Apt B, Maryland 
Heights 


(444) 444-4444 (H) 
(314) 512-3479 (W) 


i 1/20/1971 



Items 1 - 10 of 10 found 


Prev 1 Next 


f 3 pW 


Tfct- 234567 


Cbk - 363221 


Figure 3 - Driver Search - Sort Ascending on Address Column 
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Driver Search - Add 


Driver summary 1 
Driver summary 2 


REFERRAL 


Referral sum I 
Referral sum "2 


DATES /RATES 


Dates summary 1 
Dates summary 2 


BILL-TO 


Bill-To summary 1 
Bill-To summary 2 


VEHICLE/SHOP 


Vehicle/Shop 1 
Vehicle/Shop 2 

Notes summary i 
Notes summary 2 


Driver Search 


Telephone 


Contracts^^ri 


Last Name 


3 


First Name 


Drivers License Number 


Date of Birth 




: •Sia^ttJ ; -Beset ^ 



NaroeAf.- .-.>„ 

1? 



rBwHe n< wniie 



Bond, James 


Classified, Unknown 




! Jetson, <5eorae 


5 <5n;»r*lu An* 4 fi R «*rl,^« 2135474798 e«t 45678(W) 
5 Spacely, Apt 4, Sprockets 5417891234(0) 


Attsberry, James 


2002 Mateus Apt B, Maryland (444) 444-4444 (H) 
Heights (314) 512-3479 (W) 

11/20/1971 

Doe, Jane 


123 West Main, Anywhere 



1/2/1943 

! Lobochecski, Steve 







Mathews, Mik* 

Puiols. Albert 









Items 1 - 10 of 10 found 


Prev 1 Next 


Tlct - 234567 


Cfak - 363221 


-I Isi Local, intranet 


Figure 4 - Driver Search - Sort Descending on Address Column 


3. Phone number 

3.1 Behavior 

This search criteria area will be an alphanumeric field. It wil l not be formatted for presentation p urposes- 
Returns exact matches for the characters entered. A phone number is considered to be the entire number 
including area code. Example: In the United States, it would be the 3 digit area code, p lus the seven digit 
phons number. (Country Code is not considered a part of the phone number.) The search will be on all 
phone number fields associated with the Driver/Renter. Currently, these are Home. Office and Other. If the 
same phone n umber is found in multip l e areas for the same driver, the driver will only be displayed once. 
but all associated phone numbers will be listed. 

The phone number is consid ered to be a stand alone se arch criteria and a search may be executed with iust 
that sing le piece of information. 
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1- Frequent Renter 

1. User will have a single field to enter an area code and phone number. 

2. All special characters will be removed from the phone number criteria before 
the search begins. 

3.2 Validation 

None identified at this time. 

3.3 Business Exceptions 

None identified at this time. 

3.4 System Exceptions 

None identified at this time. 


4. Last Name / First Name 
q 4.1 Behavior 

1 This search criteria area w ill be a text field containing an implied wildcard after the enter ed criteria. 

The First Name field will not b e enabled until search criteria has been entered into the Last Name field. 
0! Thus, the First Name field will not be accessible via either the tab key or the mouse unless Last Name date 

I is present. 

It will return exact matches for the characters entered and will continue with othertext strings that match 
the characters entered, but are of a longer length fan implied wildcards Examp le: If the Last Name search 
criteria entered were "Smith", vou would receive back every open ticket with "Smith" in the Last name. 
+ You would also receive everv character string that matched "Smith" for the first 5 characters, but was 

flj longer than five characters. Given this, vou would also receive. "S mither". "Smithson^ "Smithy", etc. 

f jj These longer character matches would be alphabetically ascending after the exact character matches of 

1 1 " " 1 The First Name field behaves in the same manner. 


lis 
| ! 5 y 


f . 

K . s 

yj 


01 

o 

9 s 


Itshould be note d that Last Name and First Name when used in com bination, are stand alone search 
criteria and a search mav be executed with these two pieces of information. 

4.2 Validation 

First name area is disabled until there is data the last name area. 

Only having dm in the last name area is not sufficient to execute a search. 

4.3 Business Exceptions 

If only the last name area has data, and a search command is executed, then a messag^vdll±e^resentedL 
See the "error message" supplemental spec for exact text. 

4.4 System Exceptions 

None identified at this time. 

5. Driver's License Number 
5.1 Behavior 

This search criteria area wil l be an alphanumeric field. It will not be formatted for presenta tion purposes^ 
Returns exact matches for the characters entered. 

The Driver's license number is considered to be a sta nd alone search criteria and a search mav be executed 
with just that single piece of information. 
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5.2 Validation 

None identified at this time. 

5.3 Business Exceptions 

None identified at this time. 

5.4 System Exceptions 

None identified at this time. 

6. Date of Birth 

6.1 Behavior 

This search criteria area wilt be a numeric field. It will not be formatted for presentation purposes. 
The user mav e gfeLdglineating characters but these w ill be stripped out before searching the database to 
find an exact date match. There should be a calendar function available which would allow the user to 
select a date from a calendar icon, or similar feature, ins tead of entering a value. If the user selects a date 
from the calendar icons, it will be displa yed in the date area formatted appropri ately bv the l ocale, f As 

6.2 Validation 

ttwill be a valid month, day and year combination. 

Only having data in the date of birth is n ot sufficient to execute a search. 

6.3 Business Exceptions * 

If only the date of birth area has data, an d a search command is executed, then a message wi ll be presented 
. See the "error message" supplemental spec for exact text. 

6.4 System Exceptions 

Tf not a valid month, dav and year combi nation, the no rmal date in error messag e should be displayed. 

7. Results Display Area 
7.1 Behavior 

The result display will initially be blank on first presentation of the panel and until at least one search is 
executed and at least one record is found that matches the search criteria. 


This display area provides the user with the search result list. The result list wil l be comprise d of 4 static 
columns. The specific column order is: 

1) The renter's last name and first nam e will be con catenated to form this column. 

2) The renter's address. 

3) Any and all p hone numbers associate d with the particular renter. Each phone number found will also 
display it's type, either Home. Work or Other. 

4) The Renter' s date of birth, formatte d bv locale. 

The display p resentation for each type of infor mation will adhere to result list standards. 
The default sor t order is: 

1) Renter last name and first name 

2) Address. 

The users would like to have the ability to s ort the co lumns in bo th ascendin g and descending order. This 
will sort the entire result set. When a column is selected to sort, all other default or secondary sort criteria is 
abandoned. Th e manner in which Orac le sorts ascending and de scending va lues will be u sed. The display 
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area will p osition to the top of the entire result list based on the column selected to sort. 

If the user moves forward or backward within the result list, the sort w ill still be in effect. (Note: The 

phone number column is not sortahle.^ 


If the Renter is on the Do Not Rent list, a red exclamation point should be placed before the Renter Name. 

7.2 Validation 

None identified at this time. 

7.3 Business Exceptions 

None identified at this time. 

7.4 System Exceptions 

None identified at this time. 


LI 

8.1 Behavior 


8. Results Feedback Line Area 


W This feedback area provides the user with the search result list count as well as list navigation. The user 

W mav select the block of records availab le as return ed bv the invoked search criteria. These blocks are 

© identified bv sequential numbers, along with a First H st block of records) and Last flast block of records! 

**J Also appearing will the Previous and Next. When negotiating through the result list the sequential numbers 

W will chan ge depending upon the block of records being viewed, other blocks of records can be accessed via 

v the Previous and Next hyperlinks. Th e Previous and Next and appropriate blocks, sho uld be enabled or 

h* disabled according, to the positioning of the list For example, if the list were displaying the first set of 

several sets of records, the Previous fu nction would be disable d. Similarly, if the list were displaying the 
last set of rec ords the Nex t function would be disabled. 


;I 8.2 Validation 


J5S!i 


None identified at this time. 

8.3 Business Exceptions 

None identified at this time. 


8.4 


Buttons and navigation areas woul d be enabled a nd disable d appropriate ly for position of result list 
display. 


9. Button Line Area 

9.1 Behavior 

The Search ima ge/button w ill invoke the search process, submitting the form to the server. 
The Reset image/button will clear out the all of the searc h criteria data areas. 
The Cancel imag e/button will take the user to the la 

9.2 Validation 

None identified at this time. 

9.3 Business Exceptions 

None identified at this time. 
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9.4 System Excep tions 

There is a restraint of which search criteria can stand alone and on w hich a search mav be executed. 

• Phone num ber mav stand alone as one search criteria. 

• Driver's license number mav stand alone as one search criteria. 

• Last name and first name in combination, mav stand alone as one search criteria. 

• Last name and Date of birth mav no t stand alone as a search criteria and m ust be used in 
conju nction with another search criteria. 

If the appropriate amount of search criteria is not entered, then a message will be presented to the user 
stating "Additional search criteria required" 


10. Rules 

The Renter Name Last / First search criteria have an implied wild card character placed directly after the 
entered text, all other searc h criteria fields on this screen are to be treated as exact matches with searching. 

There is a restraint of whic h search crite ria can stan d alone and on which a search mav be executed. 

• The phone number alone is mav stand alone as one search criteria, 

• Driver's license number is may stand alone as one search criteria. 

• Last name and first name in combination, mav stand alone as one search criteria, 

• Last name and Date o f birth many not stand alone and must be used in conjunction with another 
$earch criteria. , 

If not sufficient search criteria has been entered, the n a message will be p resented to the user stating 
"Additional search criteria re qujrgd!!. 

When there are n ot any matches to the input search criteria the user should be pr esented wit h a feedback 
message sta ting no items/records were found for the criteria entered. 

If the search returns more reservations than can be displayed on the screen at one time, then the system 
needs to present to the user the range of records thev are viewing out of the total number of records. 


11. Security 

The user must have the appropriate security level to access this screen. The user is allowed to view or print 
anything. It is when they attempt to edit a reservation that their security restrictions will be enforced. 
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Screen Action Specification 


1. Reservation Forecasting 

This document shows the interactions a user will have when navigating through the Reservation 
Forecasting Screen. 

2. Reservation Forecasting Screen Shot 

This is the final screen shot (approved by the business) 


5 Reservation Forecasting - &tcro5offr Internet Explore r prodded by Enterprise Rent-a-Cdr , ' " llIS 


m 

m 


Detail 


Summary ^ Forecasting ' Notification 


Search 


Reservation Forecasting Starting on: SMSBjl B (mm/dd/yyyy) 


Group: 


Branch: 


01 -St. Louis 


| The First Branch 


May 25, 2001 through June 7, 2001 


Previous 14 Davs 


Next 14 Days 


Friday 

Saturday 

; i, ; Sunday£t 




? Thursday 

May 25 

May 26 

May 27 

May 28 

May 29 

May 30 # 

May 31 

12 

5 


25 

22 

IS 

15 

June 1 

June 2 

June 3 

June 4 

June 5 

June 6 

June 7 

12 

4 


22 

12 

12 

16 


6 : ; 



Tkt - 234567 


Cbk - 363221 
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3 Reservation Forecasting Microsoft Internet Explorer provided by Ertfeiprise Rent-a-Car 



hi 

m 


•3 


mi 

i 5a? 


Reservation Forecasting Starting on: Wtf/g.'L'jWj ~' cmm/dd/yyyy) 


Group: 

1 01 - St. Louis" 


Branch: 


The First Branch 


May 25, 2001 through June 7, 2001 


Previous 14 Days 


Next 14 Days 



\ Saturday 


: Monday 


Wednesday 'ii 

^FtMreda?3 

May 25 

May 26 

May 27 

May 28 

May 29 

May 30 

May 31 

12 

5 


25 

22 

18 

15 

June 1 

June 2 

June 3 

June 4 

June 5 

June 6 

June 7 

13 

4 


32 

18 

12 

# 
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Res - 411781 


Tkt - 234567 


Cfak - 363221 


Reservation Forecasting screen - Reservation Pilot version 
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2.1 Group Area 
2.11 Behavior 

This will be a combo box that displays a curre nt list of all Ren tal groups within the Peoolesoft 

hierarchy. 

The list will be: 

• Sorted in alphabetical order ascending . 

• The selection of "All" is NOT included 

• The selection of "Blank" is NOT included (A group must be chosen ). 

• The items appearing in the list are static (the user cannot add items to the list 


The users would also like to have the ability to type a character, alpha or numeric, in to the combo 
box area a nd have t he focus wit hin the list position to the character entered. (If the us er enters an 
H "H" the drop down list would p osition to the f irst string beginning with "H" in the list ) Upon initial 

tl presentation of the pa nel, this a rea should default to the group associated to the physical 

0 terminal's location. For reservation pilot, the user will not be able to chance the Group Value. 

Lf 2.1.2 Validation 

g None identified at this time. 

N 2.13 Business Exceptions 

si u 

m None identified at this time. 

|«* 2.14 System Exceptions 

llj None identified at this time. 

J| 2.2 Branch Area 
Behavior 

This will be a combo box that disp l ays a current list of all Rental Branches within the Peoolesoft 
hierarchy that are associated with the s elected Group. 
The list will be: 

• Sorted in alphabetical order ascending . 

• The selection of "All" is NOT included 

• The items a ppearing in th e list are static (the user cannot add items to the list 
dynamically) 

The users would also like to have the ability to type a character aloha or n umeric, into the combo 
box area and have the f ocus within th e list position to the character entered. (If the user enters an 
"H" the drop down list would position to the first string beginning with "H" in the list) 

Upon initial presentation of the panel, this area should default to the Branch associated to the 
physical terminal's location . If the user selects a new Group, the branch area will be set to 
"blank ". When the user selects a new Branch, the system will initiate a refresh using the new 
Group/Branch selected bv the user . For Pilot Reservation, the Branch list will NOT contain a 
blank entry. 

2.2.2 Validation 

None identified at this time 
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2.2.3 Business Exceptions 

if a user does has a "blan k" branch selected and attempts to refre sh the list, a n error message 
will be presented. See the "error message" sup plemental spec for exact text. 

2.2.4 System Exceptions 

None identified at this time. 

2.3 New Start Date Area 

2.3.1 Behavior 

This area will be a text field that will allows the user to enter the date for which thev want to start 
the 14-dav period . Upon initial presentation of the panel this field should be set to the current 
date . As soon as the user enters another date in this field, the refresh button s hould be selected. 
A refresh will be initiated when the user hits enter . 

2.3.2 Validation 

U The valid date format that must be entered is : 

• 8 numeric characters in the formant of mmddvvvv in North America 

• 8 numeric characters in the formant of ddmmyYyv in Europe 
m • Any Non-Numeric Characters will be stripped out 

Date Validation will occur when the user submits the form. If the date is not valid, the system will 
;j display the e rror "Please enter a valid date". 

i 2.3.3 Business Exceptions 


PI 


m 


If a user does not enter a date, or blanks out this area, and attempts to refresh the list, an error 
message will be presented. See the "error message" supplemental spec for exact text. 


m 2.3.4 System Exceptions 

f Ij None identified at this time. 

%i 2.4 Calendar C ontrol Area 

fx? 


2.4.1 Behavior 

When selected, the user will be shown a monthly calenda r and the user can click on a particular 
dm- The control will then populate the date selected in to the field. (A$ outlined in the HTML 
standards for Calendar Controls.) 

2.4.2 Validation 

See HTML standards for calendar controls 

2.4.3 Business Exceptions 

See HTML standards for calendar controls 

2.4.4 System Exceptions 

See HTML standards for calendar controls 

2.5 2 week period area 

2.5.1 Behavior 

The display a rea will visuall y show a 2-we ek (14 dav) period to the user . The display will show 
the dav of week, the dav f numerically) and the total number of reservations for each dav within 
the 2-week period . Initially, the firs t day within the 2-week period will be the current dav and will 
continue for the next 13 consecutive davs. A hyperlink will be available on the total number of 
reservation s number . When the user selects the hy perlink, the user will be taken to a list of that 
day's reserv ations. See the Daily R eservatio n Detail Use case for more details . 
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Other aspects of the 2-week period: 

• If a dav within the 2-week period has no reservations, the sy st em will displ ay nothing for 
that dav . 

• To help distinguish week days from weekend davs. the table will display the weekend dav 
names differently than the we ekday dav names . 

2.5.2 Validation 

None identified at this time 

2.5.3 Business Exceptions 

None identified at this time 

2.5.4 System Exceptions 

None identified at this time 

t 2.6 Table Header Area 

The Table header area will display a textual representation of the current start date and end date 
of the 2-week period. For example, if the start date was 5/14/01 and the end date was 5/28/01 . 
the table header area would be presented like this: "May 14. 2001 to May 28. 2001" . Jim 
header will change whenever the system or user selects a differen t start date . This header will 
reflect the dates that are included in the 2-week period area. 

Validation 

None 

Business Exceptions 

None 

System Exceptions 

None 

2.7 Next and Previous Area 

2.7.1 Behavior 

The next and previous button/image area will be displayed to the user. When the user select the 
next button/imaae. the system will calculate and display the next 2-week period which starts on 
the last day of the current 2-week period that is displayed . When the us er selects the previous 
button/imaae. the system will calculate and dis play th e previous 2-week period that starts 13 davs 
prior to the current start date that is displayed. 

2.7.2 Validation 

None 

2.7.3 Business Exceptions 

None 

2.7.4 System Exceptions 

If the system encounters any processing errors a ccessing the database, the system will display 
an error to the u ser that the data is unavailable . 


O 2.6.1 


m 

m 


2.6.2 


H 2.6.3 


Confidential 


©<Company Name>, 2000 


Page 8 


<Project Name> 

Version: <1.0> 

Supplementary Specification 

Date: <dd/mmm/yy> 

<document identifier^ 


2.8 Button Line Area 

2.8.1 Behavior 

The Refresh image/button will redispla y the 2-week period to reflect the most current data . Ihe 
refresh will use the same start and end dates as well as the same Group/Branch that has been 
selected . 

The New Reservation button will create a new reservation, changing the screen to that 
reservation. 

2.8.2 Validation 
None 

2.8.3 Business Exceptions 

None 

2.8.4 System Exceptions 

jf the system encounters anv processing errors accessing the da tabase, the system will display 
J an error to the user that the data is unavailable. 

«* 3. 


5S5 


srsts. 


•3- 5 

"t5 


35 

s .. 
&k 

III 

ill 

5 

: ! 


• The syste m will not include anv inactive or voided resgrya^Lons . 
3.1 Security 
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Reservation NotificationScreen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the ARMS Notification, and its 
related screens. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 

2. ARMS Notification - Most Critical and Less Critical 


'5.ARMS Indicator - Microsoft Intef net Expiorer provided by Enterprise Rent-a-Car 



These are rou^i approximations of the indicators. The actual indicators will be image files, with the Not Contacted image being | 

an animated GEF that will slowly flash | 

These indicators will appear on the far right corner of the Menu bar on the EGAE.S 2. 0 system. The m*nu bar color is the same j 

as in the table b elo w. j| 


"Contact 


"Not 


"No 

Notifications, ^ftEniptecT Contacted" 

^ S < &m „ status status 
working 


Figure 1 - Most Critical and Less Critical 


Confidential 


©<Company Name^ 2000 


Page 4 


<Project Name> 

Version: <1.0> 

Supplementary Specification 

Date: <dd/mmm/yy> 

<document identifier^ 


3. ARMS Notification - Result Display List 


3 ARMS Indicator 1/2 - Microsoft In-ternct Explorer provided by Enterprise Rcnt-a-gor 


Detail 


Summary 


Forecasting I Notification 


Search 


Reservation Notification 


a s 
Q 

m 2 


"is 



^ Pate -> ^ |^£JBbAi* ? V7T V' 1 


04/03/01 8:30 AM Attebetrv, James 


Honest Bob's Collision Repair and 
Gun Store 


02/28/01 11:35 AM 


123456 


04/10/01 8:30 AM Snuffitelii. Joe 


Firestone 


02/27/01 2:31PM 


234567 


04/10/01 


9:45 AM Smart, Maxwell 


Classified 


03/05/01 7:30 AM 


345678 


Johnston, Christine 


Cart's Auto 


04/29/01 


3:15 PM 


BG43W2 


04/01/01 6:45 AM Doe, Jane 


Fteecem Insurance 


04/01/01 6s40AM 


456789 


04/02/01 


V'eaqer, Chuck 


USAF 


04/02/01 


U23 PM 


MACH01 


04/02/01 Is 45 PM Lobochavslg Steven 


No Problem Coverage 


04/02/01 12:00 PM 5678S0 


04/03/01 2:30 PM Allen, Roger 


Pooh Insurance 


04/03/01 11:30 AM D54Q87 


Total number of reservations; 10 


Reservations in Bold are a priority. 


Tkt - 234567 Cbk - 363221 


Figure 2 - Result List Display 


4. 

4.1 Behavior 

Once a user has signed onto the ECARS 2.0 Rental Application, there mast be something that is operating 
that is able to recognize and trigger a notification to the user that a particular type of reservation has been 
added to t he Oracle database. 

• For all North American rental locations and call center locations, the notification is displayed 
when a reservation is added to the Oracle database that has an ARMS origin and the Pick-up 
Group/Branch equals the physical terminal's Group/Branch. 

• For European terminals, whenever a reservation's pick-up location has changed from 
Group/Branch UK9Z to any other valid Group/Branch Number. Once the pick-up group/branch 
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number change is committed to the database, the notification will display to the new 
Group/Branch location. (Not UK9Z). 
• For Pilot Reservation ONLY, no notification image will be present on non-North American 
screens. 


The notific ation indicators will appear on the far right corner of the Menu bar on the ECARS 2.0 system . 
The notification should be displayed on each terminal that is associated to the Physical location's 
Group/Branch Number 

The notifications will look like this (see diagram) : n The "Not Contacted" n otification will be a rectangle 
with a red border and a black car. The image will blink bv changing the background color and the car 
color. . 2) The "Contact Attempted" notification will be identical in size to the "Not Contacted" 
notification, b ut the back ground color is yellow. . 3) The "Contac ted" notification will be identical in size 
to the others, but the b ackground is green. . 

Note: The intent is to design a scalable notification method/system that can be expanded in the future which 
would allow notification(s) to be displayed to the user based on different elements or pieces of information 
contained on a reservation or contract. 


n 
m 


4.2 Validation 


SI 


m 


5 s 


*\ The system needs to det ermine which terminal is associated with a specific group, and branch (based on 

physical l ocation) so it will be able to route the notification to th e proper terminal/a) based on the 
reservation's pick-up branch location . (Example: the system will have to know all terminals located at the 
Hazelwood branch in north St. Louis county in order to send the appropriate notification to those terminals 
when an ARMS reservation is made, with a contact status of Not Contacted, with the pick-up branch being 
that Hazelwood branch). 

It will also have to determine if the branch is located in North America or Europe, (Again, probably 
• J expended to be by country, or other geographical locations, in the future). This is currently needed as 

??] North America will key off the Branch origin of ARMS, for their notifications, and the UK will key off of a 

specific branch number UK9Z. It is possible that this could be multiple branches (or what-ever is the 
notification key) in the future, so this feature needs to be expandable. 

For the immediate design, there will be a "contact status" associated with the ARMS reservations. The 
valid domain for contact status is: 

• Not Contacted 

• Contact Attempted 

• Contacted 

It is the value of the contact status, which determines the magnitude of criticality or degree of annoyance of 
the notification. 

A value of "Not Contacted" should display the notification with the greatest magnitude of criticality or 
greatest degree of annoyance. 

A value of "Contact Attempted" should display the notification with a lesser magnitude of criticality or 
lesser degree of annoyance. 

A value of "Contacted" should display the notification with no magnitude of criticality or annoyance. 
The user may elect to acknowledge the notification or not acknowledge the notification. 
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If the user does not acknowledge the notification, it always remains visible to the user, in the persistent 
state, but no further act ion is required . 


If the user acknowledges the notification the, system displays a list of all of the reservations, which 
prompted the notification. In North America this will be ARMS reservations, in Europe this will be those 
reservations with a branch origin of UK9Z. See the Results Display Area, below, for behavior after the user 
acknowledges the notification. 

4.3 Business Exceptions 

None identified at this time. 

4.4 System Exceptions 

The system w ould provide an error message of "R eservation notification system not available" if the 
notification system is down or not available for use . The error m essages will be tailored and applicable to 
what the notifica tion applies in other countries and locales. 

5. Results Disp lay Area 

5.1 Behavior 

The user has acknowledged the notification. As such, the system displays a list of all of the reservations, 
which prompted the notification. In North America this will be ARMS reservations, in the UK this will be 
those reservations with a branch origin of UK9Z. 

For Pilot Reservation ONLY, this screen will not be available to non-North American users. 

The reservation information displayed will be: 

1. Pick-up Date 

2. Pick-up Time 

3 . Renter Name - Concatenated Last Name, First Name 

4. Bill-To Account Name 

5. Reservation Creation Date 

6. Reservation Creation Time 

7. Reservation Number 

All appropriately formatted by locale. The display presentation for each type of information will adhere to 
result list standards. 

The information will be initially sorted and displayed by: 

Contact Status - All of those with a status of Not Contacted will appear before those with a status 
of Contact Attempted. 

The Not Contacted status reservation information should be in a bolder, or larger font, than the 
Contact Attempted status reservation information. (Or any other method that would make the Not 
Contacted status of reservations immediately obvious from the reservations with a status of 
Contact Attempted.) 

Within each contact status, the information will be sorted and displayed by: 

1 . Pick-up Date - In numerical ascending order. 

2. Pick-up Time - In numerical ascending order. 

For date and time sorting the following will be the standard: 

1 . Reservations with a date, but no time. 

2. Reservations with a date and a time. 
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3, Reservation with no date, but have a time. 

4. Reservations with no date and not time. 
3 . Renter's Name - In alphabetical ascending order. 


All appropriately formatted by locale. The display presentation for each type of information will adhere to 
result list standards. 

Once the results list has been po pulated with one or more reservations, the user should: 

1. Have the ability to sort anv of the columns displaye d in both as cending and d escending order. This 
will only sort the entire result set . It will sort ascending or descending on the column selected 
with out anv implied or defaulted secondary sort criteria. If the user moves forward or backward 
within the result list the sort will continue as the entire result list has been sorted. 

2. Have the capability to indicate or select an individual reservation from the result list, and perform 
a simple task, (a function button, icon, mouse click) which would then open the reservation for 
editing purposes. Within this display list the user would select a link from the Renter Name 
column to edit the reservation . This would be contingent upon the user having the appropriate 
security to edit the reservation selected. This functionality will be consistent and standard 
throughout the application. 

For all additional behavior associated with the result display list, refer to the Edit a Reservation Use Case 
and Behavior Document * 

5.2 Validation 

None identified at this time 

5.3 Business Exceptions 

None identified at this time 

5.4 System Exceptions 

None identified at this time. 

6. Button Line Area 

6.1 Behavior 

The Refresh button will reload the data and display according to the default rules. 

The New Reservation button will create a new reservation, changin g the screen to that reservation. 

6.2 Validation 

None identified at this time. 

6.3 Business Exceptions 

None identified at this time. 

6.4 System Exceptions 

None identified at this time. 

7. Subsequent ARMS Notification System Behavior 

(This will be defined in greater detail within the Edit/View Behavior Documents) 

Behavior to consider after a user edits a reservation. 
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It is envisioned that once a user selects a reservation for editing, before they will be able to save or exit the 
reservation, they must respond to some sort of dialog box, which will pose some question in the form of: 

1 . Has the renter has been contacted? With a Yes, No check box or option area. 

2. Has an attempt been made to contact the renter? With a Yes, No check box or option area. 

Based on the results or answers to the questions, the values in the particular reservation's contact status 
may be changed which will require the notification process to monitor and reflect these changes, and adjust 
the magnitude of annoyance of the notification according, if needed, as described previously. 

The exact behavior and what responses drive the changing of what values of the contact status, will be 
described as part of the Edit A Reservation development process. 

8. Security 
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Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the Notes screen. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale, 

2. Reservation Notes Screens 


3 Notes - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 


3 


DRIVERS JlMOtea 


Driver summary 1 
Driver summary 2 


REFERRAL 


Referral sum 1 
Referral sum 2 


Dates summary 1 
Dates summary 2 


BILL-TO 


Bill-To summary 1 
Bill-To summary 2 


VEHICLE/SHOP 


Vehide/Shop 1 
Vehicle/Shop 2 

Notes summary 1 
Notes summary 2 


I - Options -Jji^P 


ALL 3 

ALL _ M 



*fl '^attokh^NM Tviw : ««ated ARMS Mse 

07/03/2001 Car is aloe's Garaqe 
3i22PM 


CLOSE CALLBACK ECARS 2.0 
USER 

07/02/2001 Does not like red cars- This shows the first two tines of 

OPEN SYSTEM SYSTEM SENT 

2i 22PM the notes section. (2 @ 45 char)... 


07/01/2001 Reservation Created 
1»22PM 


RESERVATION SYSTEM SYSTEM SENT 





:£ompiete\, j 



Figure 1 - Notes 
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/3 Add Note - Microsoft Internet Explorer pro. 


Add. Note"-; 



Figure 2 - Add Note 
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3S» 


3 W 


11 
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[View Note - Microsoft Internet Explorer provided fay Enterprise Rent-a-Car 


View Note 


Date! 7/02/2001 2i22PM 

Status; Open 

Type! System 

Created By! System 

Arms Msgs Sent 

Note; 


Does not like red cars, This shows the first two lines of the 
notes section. (2 8 45 char) 

The text area shown here is big enough to show 
the entire database field without scrolling. 



■"HMfli 


Figure 3 -View Note 


hi . ! 
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-3 Notes List - Microsoft internet Explorer provided by Enterprise Rent-a-Car 


ProjectsOTMLAOpen TicketSNotesSNotesList hbnl^K^p^ 


Notes List 


Contract: 411781 
Renter: Doe Smith 
Date: 07/09/2001 


Date/ Time 

Note 

Status 

Note Type 

Created By 

ARMS Msg 


07/01/2001 
1:22PM 

Reservation Created 

Res 

System 

System 

Sent 

' 

07/02/2001 
2; 22PM 

Does not like red cars. This shows the first two lines of the 
notes section.(2 @ 45 char) 

Open 

System 

System 

Sent 

}', 1 

07/03/2001 
3:22PM 

Car is at Joe's Garage 

Close 

Callback 

ECARS 2.0 User 


, 

>\ 

Records Found: 3 





>>\ 

i.V* r 







ft/ft 

•S 

'Ms 



Figure 4 - Print All Records 


3. Reservation Notes Screen 

3.1 Reservation Number 

3.1.1 Behavior 

This area shows the unique reservation number that has be en assigned to the newlv created reservation. 
The reservation number is 6 alphanumeri c characters l on g. I anoth er reservation is open, it reservation 
number will be displayed in this are a as well. The user will have the ability to have up to 3 reservations 
o pen at a time. A hyperlink will be available on the reservation numbers of the reservations that are NOT 
currently being dis played. For the reservation that is currently d isplayed, the reservation number will not 
have a hy perlink available. This is to allow the user to navigate between the onen reservations. 

3.1.2 Validation 

None identified at this time. 

3.13 Business Exceptions 

If the user tries to open a 4 th reservation, the system will display a message statin?, "A maximum of 3 
reservations mav be displayed." 
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3. 1.4 Systems Exceptions 

None identified at this time. 


3.2 Notes Title Bar Area 

3.2.1 Behavior 

The open area i n the Notes Title Bar wi ll allow the user to acces s transaction-wide functions. These 
functions fo r Reservation are: - Options ~. Print. Void and Transfer. The default option is "—Options - 
^ The user must press the Go button to initiate the selected function. 

The Title Bar Button are a in the Not es Title Bar c ontains two buttons - a Go button and a Close button. 

The Go butto n is always active, and is used to initiate a function selected in the Options area. Iffte 
elected ontion is "—Options nothing should happen. 

The Close button is always active, and is used to close the current transaction. The button is labeled with 
an >X\ Pressing this button will cause a confirmation popup, asking the user if thev wish to cancel the 
transaction an d lose all changes. Tf the user selects 'No*, they are returned to the same screen. If the user 
selects 'Yes', the transaction is clos*H with rhwvn saved to the database. 

3.2.2 Validation 

None identified at this time. t 

3.2.3 Business Exceptions 
None identified at this time. 

3. 2. 4 System Exceptions 
None identified at this time. 

3.3 Button Line Area 

3.3.1 Behavior 

The Previous button will take the user to the Notes scree n within the same transaction. 
The Next button will take the user to die R eferral screen within the same transaction. 

The Complete button will initiate a save of the transaction. All validations will be performed returning any 
errors to the user. Tf there are no errors, the transaction will be saved, and the user is returned to the 
Reservation Home Page. 

3.3.2 Validations 

None identified at this time. 

3. 3. 3 Business Exceptions 
None identified at this time. 

3. 3. 4 System Exceptions 
None identified at this time. 

3.4 Tvoe 

3.4.1 Behavior 

This is a drop down field containing the following domain values: 
• All 
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• Bill To 

• Callback 

• Manual 

• Renter 

• Reservation 

• Shoo 

• System 

The default value is "AH". The summary list is filtered bv the item selected from the values list. The 
Status drop down list should be taken into consideration when filtering the summary list. 


Ms 

m 


s a. 

m 


3.4.2 Validation 

No validation is necessary. 

3. 4. 3 Business Exceptions 

None have been identified at this time. 


3. 4. 4 System Exceptions 
1.J None have been identified at this time. 


3.5 Status 

3.5.1 Behavior 


This is a drop down field containing the following domain values; 


• Reservation 


!p * Close 

m The default value is "Air. The summary list is filtered bv th* fram elected from the values list The Type 

drop down list should be taken into consideration when filtering the summary list 


3.5.2 Validation 

No validation is necessary. 

3. 5. 3 Business Exceptions 

None have been identified at this time. 

3. 5. 4 System Exceptions 

None have been identified at this time. 

3.6 Summary List 

3.6.1 Behavior 

The result list as describe in the use case, wi ll have a static column display sequence. AH 
columns need to have the capability to be sorted ascending and descending The user selects a 
Contract hy clicking on the hyperlink associated with the desired data row The summary MMM 
he populated with the latest note appearing first and the earliest note appearing last (descending 

order sorted by date/timeV , , . 

An ellipse (..A should he placed at the end of the note text field if the verbiage contained m the 

note exceeds 80 characters. 

The user must have the appropriate county to view/edit the contract selected. 
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This list contains the application standard for lists re garding sorting by column. 

The 'ARMS Msg* column header does not directly translate for Germany rather, it is 'ARMS'. 

3.6.2 Validation 

None have been identified at this time. 

3. 6.3 Business Exceptions 

None have been identified at this time. 

3. 6. 4 System Exceptions 

None have been identified at this time. 

3.7 Button Line Area 

3.7.1 Print All Records button 

kh 3.7.1.1 Behavior 

p The Print All R ecords butto n will essential ly generate an html report and send it to the printer. This will 

p allow the user to nrint the entire collectio n of notes associated with a contract. This report will not be sent 

p to the screen, it will only be sent to the printer. 

m 

^ 3.7.1.2 Validation 

VI No validation is necessary. * 

** 3.7.1.3 Business Exceptions 

U% None have been identified at this time. 

Ill 

f{| 3.7.1.4 System Exceptions 

|J] None have been identified at this time. 

\A. 3.7.2 Add Note button 

3.7.2.1 Behavior 

The Add Not e button will d isplay the AdH Note screen for data input. 

3.7.2.2 Validation 

No validation is necessary. 

3.7.2.3 Business Exceptions 

None have been identified at this time. 

3.7.2.4 System Exceptions 

None have been identified at this time. 

4.1 Nfite 

4.1.1 Behavior 

Thk is a free form te xt field in whi ch the user irmv enter data. 
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There must be data present in order for the note to be saved. 


4. 1.3 Business Exceptions 

None have been identified at this time. 

4. 1.4 System Exceptions 

None have been identified at this time. 

4.2 Button Line Area - Add Note 

4.2.1 OK button 
4.2.1.1 Behavior 

Tf data is not pr esent in the Note * text field the feedhack message reads. "Please enter a Note if selecting to 
Save." Two opt ions are presented, OK and Cancel- Ok will take the user back to the Add Note screen for 
I"* data entry. Cancel will dismiss the Add Note screen. 

p. Ok wilt be the default selection. 

j]} The application saves the Date/Time. Status. Tvpe. Note text and Created Bv data at the time the note is 

committed to the database. 


M Type g Manual 


s<* 4.2.1.2 Validation 

W There must be data present in the Notes text field. 

4.2.1.3 Business Exceptions 

W None have been identified at this time. 

s ; 

4.2.1.4 System Exceptions 

None have been identified at this time. 

4.2.2 Cancel button 
4.2.2.1 Behavi 



will dismiss the Add Note screer, without saving any data. 


4.2.2.2 Validation 

Tf A** has been entered the following fr*rih*dc message is displayed; "Are von sure you want to exit and 
w> the entered information? ". Two option s are presented Yes and No. Yes will dismiss the — - 
nnt onvft the data. No will take the user hark to the Add Note screen. 

The default button selec tion is "No". 

4.2.2.3 Business Exceptions 
None have been identified at this time. 

4.2.2.4 System Exceptions 
None have been identified at this time. 
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5. View Note Screen 

This is a read only screen. 

5.1 Data 

5.1.1 Behavior 

This is a listing o f the values as sociated with the selected note, this includes; 

• Date/Time 

• Status 

• Type 

• Created By 

• Arms Mess age Status 

• Note text 

The Note text field should be large enough to dis play the e ntire 510 characters as defined in the database. 

5,12 Validation 

No validation is necessary. 

5.1.3 Business Exceptions 

None have been identified at this time. 

5.1.4 System Exceptions 0 
None have been identified at this time. 

5.2 Rntten Line Area - View Note 

5.2.1 Print button 


1 5.2.1.1 Behavior 

) This button will essentiall y print a scree n print of the View Note screen. 

5.2.1.2 Validation 

There must be d ata present in t he Notes text field. 

5.2.1.3 Business Exceptions 

None have been identified at this time. 

5.2.1.4 System Exceptions 

None have been identified at this time. 

5.2.2 Close button 

5.2.2.1 Behavior 

This button will dismiss the View Note screen. 

5.2.2.2 Validation 

None have been identified at this time. 

5.2.2.3 Business Exceptions 

None have been identified at this time. 
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5.2.2.4 System Exceptions 

None have been identified at this time. 


6. 

6.1 


6.2 


Rules 

Required Fields 

The Note text field is required for creating a note. Feedback messages will he presented, as defined 
previously in this document, when a ttempting to save a note without the required information. 

Saving 

A note must be defined before the 


7. Security 

The user must have tl 
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Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the Referral Source screens. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 

2. Referral Source Screen 


3E38466 0101 Enterprise* ECAR5 Application - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 
. __. . 1 ;m i»j— —————— — «■■———————— —■ 


DRIVERS 


r Referral 



Referral Source 


Account- 


Account Name: 
(-Select- 
Contact Name: 

f-Sei ecH 


C "-Employee N umber 

' L ' 


VEHICLE/ SHOP 


NOTES 


Notes Taken : i 


r Referral Detail- 


Account Number: 


L 


Phone Number 


sues 



Figure 1 - Referral Source Screen 


Figure 2 - Referral Source Screen (Employee selected) 
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Account Name 
Contact Name 


DATES/RATES 


08/27/2001; ECAR 
Daily Rate; ASD 

3 

Account Name 
Contact Name 


VEHICLE/SHOP 


1997 Dodge Avenger 
Shop Account Name 


Notes Taken: 1 
Changed: 


GE1658 Corporate 0101 6275 Delmar St. Louis MO 63130 (314)721-6127 


A Collector's 
Bookstore** 


A.f.i, Remodeling SE1225 Corporate 0102 312 Oak Pic, Wildwood MO 63040 (636)458-1552 
Co** Village Dr. 


Accent Lincoln- 


mercury" 


129498 Dealership 0103 9700 St Louis MO 63119 (314)968-5300 

Manchester 
Rd 


Advantage 
Decorating** 


0EQ853 Corporate 0104 1601 North St. Louis MO 63102 (314)436-1419 ^ 
7th St. 

African Amer. Rite Of GE1538 Corporate 0105 325 St. Louis MO 63112 (314) 361-2268 '' 

Passage** Debaliviere . 


Ahzad Booosian** GH0830 Corporate Q1Q6 7743 Arthur St. Louis MO 63117 (314) 645-3076 tj 


Aio-cs*« 


SE0233 Corporate 0107 120 S St Louis MO 63105 (000)000-0000 

Central, Ste 
300 


Al-oac, Inc.** 


GE1350 Corporate 0108 18535 Old Pacific MO 6^3069 (636)271-8222 

Hwy66 


Alhertin Auto Body <308S68 Bodyshop 0109 8449 Page St Lours MO 63130 (314)423-9924 -, 
Inc** ., 


Allen*Wnette* 


E75477 Employee 0110 600 <3ien Shiloh 
AHdi» 


IL 62221 (314)863-0055 


•J 

i 



TH Tkt - 234567 


Cbk - 363221 
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3 E38466 0101 Enterprise* ECARS Application - Microsoft Internet Explorer provided by Enterprise R en t-a-Cai 


Referral Source 


Resery 


DRIVERS 


REFERRAL 


DATES /RATES 


BILL-TO 


VEHICLE/SHOP 


NOTES 


Notes Taken : 1 


-Options- 


hbh-i 


Figure 3 - Referral with Branch Short List 



-Referral 

C p Account-' 
1 (Account Name: 

Account Number: 



| 

[-Select- _ ^ 23 

1 _. 




Contact Name: 


Phone Number 



(-Select- 

mmmm 



PI 

-Employee Number 










- — ~ — ' __ 
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% Account Search - Microsoft Internet Explorer provided by Enter prise ;Ren^a|3BB| 


fallbacks ^k- 


[1 Account Search ■ 

Group: 












|pi- St Loire 












Account Name 


Account Phone Number 



Account Type 










(All 


zi 










mi 


\ vv'- ■ -a 

.-i-K.; ■' 






^ Number r 


GP/BR LAccbmt Address .^vexv £ l 


Estate? zsd-K^ 

Phone- Number? i 

A Collector's Bookstore** 

GE1653 

Corporate 

0101 

6275 Delmar 


St. Louis 

MO 

63130 

(314)721- £ 
6127 ; 1 - 











A.f.i, Remodelinq Co** 

GE1225 

Corporate 

0102 

312 Oak Pk, Village Dr. 

Wildwood 

MO 

63040 

636 458-1552 

Accent Lincoln-mercury** 

129498 

Dealership 

0103 

9700 Manchester Rd 

St Louis 

MO 

63119 

(314) 968-' 'V'. 1 
5300 











Advantaae Deeoratina** 

6E0853 

Corporate 

0104 

1601 North 7th St. 


St. Louis 

MO 

63102 

(314)436- f 











1419 , 

African Amer. Rite, Of Passage** 

GE1538 

Corporate 

0105 

325 Debaiiviere 


St Louis 

MO 

63112 

314 3612268 / 

Ahzad Boqosian** 

GE0830 

Corporate 

0106 

7743 Arthur 


St. Louis 

MO 

63117 

(314) 645- 











3076 

Aiq-cs** 

GE0238 

Corporate 

0107 

120 S Central, Ste 300 

St Louis 

MO 

63105 

(000)000- N v 








it 



0000 

Ai-pac, Inc.** 

GE135Q 

Corporate 

0108 

18535 Old Hwy 66 


Pacific 

MO 

63069 (636)271-8222 \ 

Albertin Auto Bodv Inc** 

_G08868_ 

Bodyshop 

0109 

8449 Page 


St Louis 

MO 

63130 

(314) 423- /£j 












Items 1 - 66 of 66 found 


Prev 1 2 3 4 5 Next 


Res - 41X781 


Tkt- 234567 


jcbk- 


363221 


'Local irfcranefc ; \ , » ,v s ^ 


EkureA=-A ccount Search Screen 
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■^3 Account Search - Microsoft Internet Explorer prodded by Biterpiise Rentf a|§^ 



i 


Account Search 


jGontrBbts; 


Group: 

|01 : StLoui 


s 


Account Name 


Account Phone Number 


Account Type 


All 


^GP?BR fl&oUn* Address j CT&y 


A Collector's Bookstore** 


3E1653 Corporate 0101 6275 Delmar 


St. Louis MO 


63130 (314)721- ^ 
6127 


A.f.j. Remodeling Co* 


GE1225 Corporate 0102 312 Oak Pk. Village Dr. Wildwood MO 63040 636 458-1552 


Accent Lincoln-mercury* 


129493 Dealership 0103 9700 Manchester Rd 


StLouis MO 63119 (314)963- 

5300 


Advantage Decorating** 


GEQ853 Corporate 0104 1601 North 7th St. 


St. Louis MO 63102 (314)436- 

1419 


African Aroer. Rite Of Passage* 


GE1538 Corporate 0105 325 Debaliviere 


StLouis MO 63112 314 3612268 


Ahzad Booosian** 


GE0830 Corporate 0106 7743 Arthur 


St. Louis MO 


63117 (314)645- 
3076 


GE0238 Corporate 


Al-oac. Inc.** 


GE1350 Corporate 


0107 
0108 


120 S Central Ste 300 


St Louis MO 

0 


63105 


(000) 000- 
0000 


18535 Old Hwy 66 


Pacific MO 63069 (636)271-3222 


Alberdn Auto Body Inc 


G08868 Bodyshop 0109_ 8449 Page 


StLouis MO 63130 (314)423- J^j 


Items 1 - 66 of 66 found 


Prev 12 3 4 5 Next 


Res - 411781 


[ Tkt - 234567 [ Cbk - 363221 1 


Figure 4.1 -Accour 


>ilot Reservatic 
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^Employee Search - Microsoft Internet Explorer provided iby Erfterprfe 


Employee Search 


Last Name 


First Name 



Department 


Adams, Edward 


12345 0101 - Group Name - Branch Name 


D/R 


BRANCH 
MANAGER 


Adams, Mark 


23456 0202 - Group Name - Branch Name 


MIS 


BUSINESS 
ANALVST II 


Adkins. Cindy 


34567 0303 - Group Name - Branch Name 


USED CAR 


DETAILER 


Ahne, Susan 


46789 0404 - Group Name - Branch Name 


ADMIN 


DEPARTMENT^ 
MANAGER 


Alaqappiranar, Seenivasan 37954 0505 • Group Name - Branch Name 


NAT RES 


BRANCH 
MANAGER 


Albers, Jen 


5641G 0606- Group Name- Branch Name 


D/R 


BUSINESS 
ANALVST II V 


Aliens Karen 


6547E 0707 - Group Name - Branch Name 


MIS 


DETAILER 


6542D 0101 - Group Name - Branch Name 


USED CAR 


DEPARTMENT, 
MANAGER 


Anantharam, Paras uram 6546F 0202 - Group Name -Branch Name v ^..^ ADMIN , t , BRANCH * 



Items 1 - 22 of 22 found 


Prev 123 45 Next 


•Loealintranet 


A. 


Figure 5 - Em ployee Search Screen 
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5 Add New Contact - Microsoft Internet Explorer provided by Enterprise Bent-a^ar; 



. nSh. Home j Search Favorites Histay Mag Prtnt Ec& Discuss , - ■ • = 

1 ' 1 1 ' 1 1 1 ' ' ■ ■- --' ■'— ■ "'~ t ■ ■:•-..<;..■ ■ • ■ 


I C:\M\Reservation\RefenaIVWdContatf.hM 


Add New Contact 


Last Name 
First Name 



Figure 6 - Add New Contact Screen 


3. Reservation Number 

3.1 Behavior 

This area shows t he unique rese rvation number that has been assigned to the newly created 
reservation. The reservation number is 6 alphanum eric characters long, if another reservation is 
o pen, its reservation number will be displayed in this are a as well. The user will have the ability 
to have up to 3 reservations open at a time. A hyperlink will be av ailable on the reservation 
numbers of the reservations that are NOT currently being displayed. For the reservation that is 
currently displayed, the reservation number will not ha ve a hyperlink available. This is to allow 
the user to navigate between the open reservations, 

3.2 Validation 

None identified at this time. 

3.3 Rnsinsss Exceptions 

If the user tries to open a 4 th reservation the s ystem w ill display a message stating. "A maximum 
of 3 reservations mav be displayed". 
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3.4 System Exceptions 

None identified at this time. 


4. Referral Title Bar Area 

4.1 Behavior 

The open area in the Referral Title Bar will allow the user to access transaction-=wide fu nctions. These 
functions for Reservation are: - Potions Print. Void and Transfer. The default option is "— Options - 
^ The user must press the Go button to initiate the selec ted function. 

The Title Bar but ton area in the Referral Ti tle Bar contains two buttons - a Go butt on and a Close button. 

The Go button is always active, an d is used t o initiate a function selected in the Option area. If the 
selected option is "—Options nothin g should happen . 

The Close button is always active a nd is used to close the current transaction. The button is labeled with an 
'X'. Pressing this button will cause a confirmat ion popup, asking the user if they wish to cancel the 
transaction and lose all changes. Tf the user sele cts 'Yes', the transaction is closed with no changes saved 
to the database. 

4.2 Validation 

None identified at this time. 

4.3 Business Exceptions 

None identified at this time. 

4.4 System Exceptions 

None identified at this time. 


5. Account and Employee Number Radial Button 
5.1 Behavior 

These two b uttons are mutually exclusive. Only one or the othe r mav be selected. If a radial 
button is selected, with out anv other information input and then the search button is selected, 
and then the a ppropriate searc h panel is presented. For example, if the Account radial button is 
selected, no information is entered, and the search button is selec ted, then the Account Search 
panel is display ed, if the Em plo yee Number radial but ton is selected, no information is entered. 
and the search button is selected, then the Employee Search panel is displayed. This should 
default to the "Account" selection. 


5.2 Validation 

None identified at this time. 

5.3 Business Exceptions 

None identified at this time. 

5.4 System Exceptions 

The system will only allow on e or the other to be selected . 
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6. Account Name/Short List Area 

6.1 Behavior 

This area is a dro p down area comprised of the Branch's short list. If a search is executed on the 
account number and a single, valid match is found, this area will be filled with the co rresponding 
account name. 

Information displa yed in the short list is: 

• Account Name 

• Account Number 

• Account Type 

• Owning Group and Branch Number 

• Account Stre et Address 

• Account Citv 

• Account State 

• Account Zip Code 

• Account Telephone Numbers) 


By selecting an Account from this short list all of the appropriate information will be populated into 
the detail section. 

6.2 Validation 

None identified at this time. 

6.3 Business Exceptions 

None identified at this time. 

6.4 System Exceptions 

None identified at this time. 

7. Account Number Area 

7.1 Behavior 

This is a free form alphanumeri c area. An entry into this area is valid to execute a search. 

7.2 Validation 

None identified at this time. 

7.3 Business Exceptions 

None identified at this time. 

7.4 System Exceptions 

None identified at this time. 

8. Contact Name Area 
8.1 Behavior 

This area is disa bled and unpop ulated until a valid Account Name and/or Account Number has 
been selected, or enter ed and the detail returned from the database. Once a single and valid 
Account has been returned then this wil l be a drop down list populated with the contact(s) 
associated with that Account. 
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8.2 Validation 

None identified at this time. 

8.3 Business Exceptions 

None identified at this time. 

8.4 System Exceptions 

None identified at this time. 

9. Phone Number 
Behavior 

This is an alphanumeric field that is populated with the contact Phone number once a 
contact is sele cted by the user. Onc e the field is populated, the user should have the 
ability to Chang e this field. It the user changes the field: the changes will only be saved at 
the transaction level and will not affect the reference data. For reservation pilot, ail of the 

contacts will display the ac count phon e number in the Contact phone numb er field. This 

is because c urrently T we are not storing contact phone numbers or extensions with for a 

particular account* 

9.1 Validation 

None identified at this time 

9.2 Business Exceptions 

None identified at this time 

9.3 System exceptions 

None identified at this time. 

10. New Contact Button 

10.1 Behavior 

Selecting this button will display the New Contact panel. The button is not enabled until a valid 
Account Name or Number is entered or selected and th e detail is displayed. 

10.2 Validation 

None identified at this time. 

10.3 Business Exceptions 

Tf the Account Type, associated with this Account is Fleet then thi s button wil l be disabled. 

10.4 System Exceptions 

None identified at this time. 

11. Employee Number Area 

11.1 Behavior 

This area is a free form text area that will allow the user to inpu t alphanumeric values. An entry to 
this area is valid to execute a search. 

11.2 Validation 

None identified at this time. 

11.3 Business Exceptions 

None identified at this time. 
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1 1 .4 System Exceptions 

None identified at this time. 

12. Search Button 


12.1 Behavior 

A search may be executed if either the Account Number area has values entered or the 
Employee Number area ha s values entered. The system will search for exact matches and 
display either the detail if a single match is f ound or the Account Search panel or Employee 
search panel if multiple matches are found. If neither area has values entered and the search 
button is executed then either the Account Search panel or the Employee Search panel will be 
displayed depending on which radial button is selected. 

12.2 Validation 

None identified at this time. 

12.3 Business Exceptions 

If no matches are found the message "0 record of 0 records were found". Or whatever the standard verbiage 
is displayed. 

12.4 System Exceptions 

None identified at this time. 

13. Referral Detail Area * 
13.1 Behavior 

Ihjs are will be populated with either Ac count or Em ployee Number detail if a single match is 
found. 

For an Account th e displayed info rmation is: 

• Account Name 

• Account Number 

• Owning Group and Branch 

• Account Type 

• Street Address 

• QM 

• State 

• Zm 

• Phone Numbers 
From Special Instructions 

• 2 "Hot" lines 

• Miscellaneous Information 

• Discounts 

• Rules 

• Products 

For an Employee the displayed information is: 

• Employee Name 

• Employee Number 

• Group and Branch Number 

• Group and Branch Description 

• Department 

• Title 
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13.2 Validation 

None identified at this time. 

13.3 Business Exceptions 

None identified at this time. 

13.4 System Exceptions 

None identified at this time. 

14. Button Line Area 
14.1 Behavior 

The Previous button will take the user to the Driver screen within the s ame transaction. 
The Next button will tak e the user to the Dates/Rates within the same transaction. 

The Complete button will initiate a save of th e transaction . AH validations will be performed, returning anv 
errors to the user . If there are no errors, the transaction is saved and t he user is returned to the Reservation 
tt homepage. 

m 14.2 Validation 

None identified at this time. 

14.3 Business Exceptions 

None identified at this time. 

14.4 System Exceptions 

■ y None identified at this time. 

ilj 

i • ST 


15. Search - Group Area 

15.1 Behavior 

This area will be a drop down list of all g ro ups. It will default to the terminal's group. The option of 
All is also available. For reservation pilot, the u ser will not be able to change the group value. 

15.2 Validation 

None identified at this time. 

15.3 Business Exceptions 

None identified at this time. 

15.4 System Exceptions 

None identified at this time. 

16. Search - A ccount Name Area 

16.1 Behavior 

This area will allow entry of alphanumeric values. The system will search on exact matches for the 
values entered with an im plied wild ca rd at the end. 

16.2 Validation 

None identified at this time. 
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16.3 Business Exceptions 

If no matches are found the message "Q recor d of Q records were found". Or whatever t he standard verbiage 


16.4 System Exceptions 

None identified at this time. 

17- Search - Account Phon e Number Area 

17.1 Behavior 

This area will allow entry of alphanumeri c values. The system will search on exac t matches without 
any imp lied wild cards. 

17.2 Validation 

None identified at this time. 

17.3 Business Excep tions 

If no matches are found the message "0 record of 0 records were found" Or whatever the standard verhiaae 
is displayed. 

17.4 System Exceptions 

None identified at this time. 

0 

18. Search - Account Type Area 

18.1 Behavior 

This area will be a drop down list of account ty pes. It will default to All. 

The domain values are: 

• Body Shop 

• Corporate 

• Government 

• Fleet 

• Dealership 

• Insurance 

• Other 

• AU 

18.2 Validation 

None identified at this time. 

18.3 Business Exceptions 

The system cannot execute a search on Account Type alone. Either a Group. Account Name 
and/or Account Phone Numb er is also required. If oniv A ccount Type is selected a message is 
displayed "Must specify another search criteria". 

A search cannot be executed if the Grou p selection is "All" and the Account Type selection is 
"Alt", with Account Name and Account Phone Number without values. Group or Account Type 
must have a value selected. If both are "All" display error message to user "Gro u p and Account 
Ty pe cannot both be All". 

18.4 System Exceptions 

None identified at this time. 
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19. Search - Display Area 
19.1 Behavior 


The result display will initially be blank on first pres entation of th e panel and until at least one search is 
executed and at least on e record is fo und that matches the se arch criteria. 


• Account Name 

• Account Number 

• Account Ty pe 

• Owning Group and Branch Number 

• Account Street Address 

• Account City 

• Account State 

• Account Zip Code 

• Account Phone Numbers) - If the search was on Phone Number, then this will 
display the match with the search criteria, whether Home Work or Other phone 
number. In all other circumsta nces, the work phone number should be dis played. 

The users would like to ha ve the ability to sort the columns in both ascending and descending order. This 
will sort the entire r esult set. W hen a colu mn is selected to sort, all other default or secondary sort criteria is 
abandoned. The manner in which Orac le sorts ascending and descending values will be used. The display 
area will position to the too of the entire result list based on the column sele cted to sort. 

If the user selects an Account Name, the referral source panel will be presented with the appropriate 
information. 

19.2 Validation 

None identified at this time. 

19.3 Business Exceptions 

None identified at this time. 

19.4 System Exceptions 

None identified at this time. 

20. Employee Search - Last Name Area 

20.1 Behavior 

This area will allow entry of alphanumeric values. The system will search on exact matches for values 
entered with an implied wild card at the end. Values in the Last Name area alone is valid to execute a 
search. 

20.2 Validation 

If no matches are found th e message "0 record of 0 records were found". Or whateve r the standard verbiage 
is displayed. 

20.3 Business Exceptions 
I 

None identified at this time. 
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20.4 System Exceptions 

None identified at this time. 

21. Employee Search - First Mam* 

21.1 Behavior 

This area will allow entry of alphanumeric v alues. The syst em will search on exact matches for the 
valuesentered with an implied wild card at the end. This area will he disabled until a value has been 

21.2 Validation 

None identified at this time. 

21.3 Business Exceptions 

If only the first name area has data, and a search c ommand is exec uted then a message will be presented tn 
the user stating. "Must Specify a Last Name" 


■JiSS; 

m None identified at this time. 

m 

"is 
a s 


21.4 System Exceptions 


22 - Employee Search - Display Ai-aa 


yj 22.1 Behavior 

executed and^t least one record is found that matches the' search criteria^ " ================ 


m 


This is a results list area. The following informatio n is display ed: 

• Employ ee Name 

• Employee Number 

• Group and Branch Numher 

• Group and Branch Description 

• Department 


Since the Employee data is coming from a tuxedo call, the user will not be allowed the ability to sort on a 
column in th e search results 

If the user selects an Employee Name, the referral source panel will be presented with the approp riate 
information. 

22.2 Validation 

None identified at this time. 

22.3 Business Exceptions 

None identified at this time. 

22.4 System Exceptions 

None identified at this time. 


Confidential 


©<Company Name>, 2000 


Page 21 


<Project Name> 

Version: <L0> 

Supplementary Specification 

Date: <dd/mmm/yy> 

<document identified 


23. Search. Reset and Cancel Button Line Area 

23.1 Behavior 

The Search image/button will invoke the s earch process , submitting the form to the server. 

The Reset image/button will clear out the all of the search criteria data areas and reset the panel to the 
initial values. 


23.2 Validation 

None identified at this time. 

23.3 Business Exceptions 

None identified at this time. 

23.4 System Exceptions 

None identified at this time. 

24. Print Current Page and Print All Records Button Line Area 

24.1 Behavior 

The Print Current Page image/button will print the information currently displayed on the panel. 
The Print All Records image/button will print the information in the entire result set list. 

24.2 Validation 

None identified at this time. 

24.3 Business Exceptions 

None identified at this time. 

24.4 System Exceptions 

None identified at this time. 

25. Add New Contact - Last Name Area 

25.1 Behavior 

This area will allow entry of alphanumeric values. 

25.2 Validation 

None identified at this time. 

25.3 Business Exceptions 

None identified at this time 

25.4 System Exceptions 

None identified at this time. 

26. Add New Contact - First Name Area 
26.1 Behavior 
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26.2 Validation 

None identified at this time. 

26.3 Business Exceptions 

None identified at this time 

26.4 System Exceptions 

None identified at this time. 


27. Ok and Cancel Button Area 
27.1 Behavior 

The "Ok" ima^e/button will attempt to add the information entered to the database, invoking the 


27.2 Validation 

If the user hits the "Ok" button and there is no data in either the Last Name and/or First Name fields, the 
system will display an error message that says "Must enter a First Name and/or Last Name." 

27.3 Business Exceptions 

None identified at this time. 

27.4 System Exceptions 

None identified at this time, 

28. Security 

The user must have the appropriate security level to access these screens. The user is allowed to view or 
print anything. It is when they attempt to edit a reservation that their security restrictions will be enforced. 




the last panel accessed . 
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4.3.1.1 Behavior 

4.3.1.2 Validation 

4.3. 1 .3 Business Exceptions 

4.3 . 1 .4 System Exceptions „ 

4.3.2 Cancel button 
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4.3.2.1 Behavior 28 

4.3.2.2 Validation 28 

4.3.2.3 Business Exceptions 28 

4.3 .2.4 System Exceptions 28 

5. Rules ...28 

5.1 Year, Make and Model domain values come from the database 28 

5.2 A Contact must be selected for every Account that is selected as a Shop.Error! Bookmark not defined. 

5.3 The system should not search for or display any deactivated Accounts 28 

5.4 User needs to have ability to cancel a search at any time during the search 28 

5.5 Notes should be generated when any of the following events occur: 28 

6. Security 29 
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Screen Action Specification 

1 . Introduction - Renter's Vehicle/Sho p Screen Spec 

This document will describe the behavioral characteristics associated with the Renter's Vehicle / Shop 
screen. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 
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2. Screen Prints 


3 Vehicle / Shop - fficrosoft Internet Explorer provided by Enterprise Rent-a-Car 
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Figure 1 - Vehicle / Shop (North America^ 
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Figure 2 - Vehicle / Shop (Ireland & United Kingdom) 
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-3 Vehicle / Shop - Germany - Microsoft I nternet Explorer provided by Enterprise Rent-a-Car 
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Figure 3 - Vehicle / Shop (Germany) 
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3 Vehicle / Shop - Germany - Microsoft Internet: Explorer provided by Enterprise Rent-a-Car 


j^^gf jAj^ess- Y^APPS^cys^Devebptnent Projects\HTML\Open Ticket\5hop\VehideS6hop-germany.html jjj 


Vehicle/Shop 2 

Notes summary 1 
Notes summary 2 


DRIVERS 

Renter's Vehicle 

Driver summary l 
Driver summary 2 

-Vehicle 1 

Registration Number 

REFERRAL 

t __„• 

Year 

Referral sum 1 
Referral sum 2 

1 d 

Make 

DATES/ RATES 

Date 5 summary 1 
Dates summary 2 

L -1 

BILL-TO 

Model 

Bill -To summary 1 
Bill-To summary 2 

l_ zl 

Color 

VEHICLE/SHOP 

1 

Vehicle/Shop 1 



Not on File 


Name" 1 


•pe 
Loss 


L_ 


Address* 


ate of Loss 


■3 - 


Zip* 


._ __ a 

Country* 


"3 


City"* 


State' 1 


Shop 


r 


r 


rShop 

Account Name 


Contact Name 


V 


Phone Number* 


Contact Last Name 


[ZZ — 

Contact First Name 

I 


•:V' 


OK] ;ACaflce^ 


Oomplete. J c 


Res v 411781 


Tkt - 234567 Cbk - 363221 


Figure 4 = Add Acco unt Not On File 
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<jj Vehicle / Shop - Germany - Microsoft Internet Explorer provi ded by Enterprise Rent-a-Car 
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Figure 5 - New Contact 
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Vehicle / Shop (Figure 1, Figure 2, Figure 3) 

2.1 Reservation Number 

2.1.1 Behavior 

This area shows the unique reservation number that has been assign ed to the newlv created reservation. 
The reservation number is 6 a lphanume ric characters long. If another reservation is open, its reservation 
number will be displ ayed in thi s area as we ll. The use r will have the ability to have up to 3 reservations 
open at a time. A hyperlink will be availab le on the re servation numbers of the reservations that are MQT 
currently being displayed. For the reservation that i s currently displayed, the reserv ation numbe r will not 
have a hyperlink available. This is to allow the u ser to nav igate between the open reservati ons. 

2.1.2 Validation 
None identified at this time. 

2.13 Business Exceptions 

If the user tries to open a 4 th reservation, the system will d isplays messas 
M reservations may be displayed." 

ffj 2.1.4 System Exceptions 
OS None identified at this time. 


S 1 


01 


2.2 Vehicle/Shop Title Bar Area 


m 

if 2.2.1 Behavior 


The option area in the Vehicle/Shop Title Bar will allow the user to access transaction-wide functions. 
fU These junctions for Reservation are: -Options a Print. Void and Transfer. Thedef 

!U Options-". The user must press the Go button to initiate the selected ftmction. 


I The Title Bar button area in the Vehicle/Shop title bar contains two buttons - a Go button and a Close 

{** button. 

The Go button is always active, and is used to initiate a function selected in the Options area. If the 
selected option is "—Options—", nothing should happen. 

The Close button is always active, and is used to close the current transaction. The button is labeled with 
an 'X ? . Pressing this button will cause a confirmation popup, asking the user if they wish to close the 
transaction and lose al l changes. If the user s elected 'No*, thev are returned to the Vehicle/Shop , 
If the user selects 4 Yes', the transaction is closed with no changes saved to the database. 

2.2.2 Validation 
None identified at this time. 

2. 2.3 Business Exceptions 
None identified at this time. 

2. 2. 4 System Exceptions 
None identified at this time. 

2.3 Button Line Area 

2.3.1 Behavior 

The Previous button will take the user to the Bill-to screen within the same transaction. 
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The Next button will take the user to the Notes screen within the same transaction. 

The Complete button will initiate a save of the transaction. All valid ations will be performed returning anv 
errors to the user. If there are no errors, th e transaction is saved, and the user returned to the Reservation 
home page. 

23.2 Validation 

None identified at this time. 

2.3.3 Business Exceptions 

None identified at this time. 

2.3 A System Exceptions 

None identified at this time. 

2.4 Registration Number (V ehicle area Of Renter's Vehicle sub-screen) 

2.4.1 Behavior 

This is a text field in which the user mav ent er a Regis tration Number This field only appears on the 
European versions of the application and is hidden on the North American version. 

2.4.2 Validation 

No validation is necessary. 

2.4.3 Business Exceptions 

None have been identified at this time. 

2. 4. 4 System Exceptions 

None have been identified at this time. 

2.5 Year (Vehicle area of Renter's Vehicle sub-screen) 

2.5.1 Behavior 

This is a drop-down field containing the Years available for searching. This field is hidden on the Ireland 
and United Kingdom version of the application and is visible on the North American and German versions. 

2.5.2 Validation 

No validation is necessary. 

2. 5.3 Business Exceptions 

None have been identified at this time. 

2. 5.4 System Exceptions 

None have been identified at this time, 

2.6 Class (Vehicle area of Renter's Vehicle sub-screen) 

2.6.1 Behavior 

This is a drop-down field containing a list of numbers from 1 to 10 for the User to select as the Class. 
This field only appears on the German version of the application and is hidden on the North American and 
the Ireland and United Kingdom versions. 

2.6.2 Validation 

No validation is necessary. 
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Z 6, 3 Business Exceptions 

None have been identified at this time. 

2. 6. 4 System Exceptions 

None have been identified at this time. 

2.7 Make (Vehicle area of Renter's Vehicle sub-screen) 

2. 7. 1 Behavior 

Jhis is a drop -down fiel d containing a list of Makes for the Year selec ted. Tf a M ake different from "Other 
Make" is selected from the list the Other M ake field s hould be cleared out. This field appears on all 
versions of the application. 

2.7.2 Validation 

No validation is necessary. 

2. 7. 3 Business Exceptions 

None have been identified at this time. 

2. 7. 4 System Exceptions 

None have been identified at this time. 

2.8 Other Make A/ehicle area of Renter's Vehicle sub-screen) 

2.8.1 Behavior * 

This is a text field in which the user may enter a Make that was not available in the drop-down. If a value is 
entered, the Make drop-down field sh ould be cleared out if it has a value different from "Other M ake". This 
field appears on all versions of the application. 

2.8.2 Validation 

No validation is necessary. 

2. 8.3 Business Exceptions 

None have been identified at this time. 

2. 8. 4 System Exceptions 

None have been identified at this time. 

2.9 Mode! (Vehicle area of Renter's Vehicle suh-screenl 

This is a drop-down field containing a list of Models for the Make selected. If a Model different from 
"Other Model" is selected from the list the Other Model field should be cleared out. This field appears on 
all versions of the application. 

2.9.2 Validation 

No validation is necessary. 

2.9.3 Business Exceptions 

None have been identified at this time. 

2. 9. 4 System Exceptions 

None have been identified at this time. 
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2.10 Other Model ( Vehicle area of Renter's Vehicle sub-screen! 

2.10.1 Behavior 

This is a text field in which the user mav enter * Model that was not available in the drop-down. If a value 
is entered, the Model drop-down field should be cleared out if it has a value different from "Other Model". 
This field appears on all versions of the application. 

2.10.2 Validation 

No validation is necessary. 

2.10.3 Business Exceptions 

None have been identified at this time. 

2.10.4 System Exceptions 

None have been identified at this time. 

2.11 Cnlftr /Vehicle area nf Renter's Vehicle sub-screenl 


2.11.1 Behavior 

This is a drop-down field containing a list nf available colors. If a Color different from "Other Color" is 
selected from th e list the Other Color field should be cleared out. This field appears on all versions of the 
application. 

O 2.11.2 Validation > 
No validation is necessary. 

8 ii 5 

r 2.11.3 Business Exceptions 

|-% None have been identified at this time. 

\l\ 2.11.4 System Exceptions 

None have been identified at this time. 

2.12 Other Color (Vehicle area o f Renter's Vehicle sub-screen! 

2.12.1 Behavior 

This is a text field in which the user mav enter a Color that was not available in the dron-down. If a value is 
Entered, the Color drop-down fi eld should be cle ared out if it has a value different from "Other Color". This 
field appears on all versions of the application. 

2.12.2 Validation 
No validation is necessary. 

2.12.3 Business Exceptions 
None have been identified at this time. 

2.12.4 System Exceptions 
None have been identified at this time, 

2.13 Is nar Drivable? (Loss Inform ation area of Renter's Vehicle sub-screen) 

2.13.1 Behavior 

This is a dron down field containing the following domain values: 

• miantt - Default 

• m 

This field appears on all versions of the application. 


Confidential 


© Enterprise Rent-A-Car, 2001 


Page 18 


Rental Redesign 

Supplementary Specification 
Vehicle / Shop 


Version: 2.7 
Date: 12/21/2001 


2.13.2 Validation 
No validation is necessary. 

2.13.3 Business Exceptions 
None have been identified at this time. 

2.13.4 System Exceptions 
None have been identified at this time. 

2.14 Type of Loss? (Loss Info rmation area of Renter'** Vehicle sub-screen! 

2.14.1 Behavior 
This is a drop down field c ontaining the following domain values: 

• mianlrt- Default 

• Damage 

• Theft 

This field appears on all versions of the application. 

2.14.2 Validation 

□ No validation is necessary. 

2.14.3 Business Exceptions 


gars 


: i 

f 1 None have been identified at this time. 

"!3~ 


2.14.4 System Exceptions 

None have been identified at this time. 
»l 2.15 Tnial Loss? (I ggg Information area of Renter's Vehicle S«lb-SCreenl 


m 2.15.1 Behavior 

j<H This ifs a drop down field containing the following domain values: 

• mianlrt - Default 

• Ym 
•He 

This field appears on all versions of the application. 

2.15.2 Validation 
No validation is necessary. 

2.15.3 Business Exceptions 
None have been identified at this time. 

2.15.4 System Exceptions 
None have been identified at this time. 

2.16.1 Behavior 

Thk is a text field in »^ ™»v gnjg a date value. This field appears on all versions of the 

application. 

Entered data should be in a MM/DD/YYYY format, 

2.16.3 Business Exceptions 

None have been identified at this time. 
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2.16.4 System Exceptions 

None have been identified at this time. 

2.17 Calendar butt on (Loss Info rmation area of Renter's Vehicle sub-screen^ 

2.17.1 Behavior 

This will bring up a calendar pop-up window allowing the user to select a specific date. The selected date 
will fill the Date of Loss field. This button appears on all versions of the application. 

2.17.2 Validation 
No validation is necessary. 

2.17.3 Business Exceptions 
None have been identified at this time. 

2.17.4 System Exceptions 
None have been identified at this time. 

2.18 Theft Waiver Da y 5 ( Lqss In formation area nf Renter's Vehicle sub-screen! 

y 2.18.1 Behavior 

This is a drop down field containing the follow! 


m 

0 

• 2 Days 

• 3 Davs 

This field only appears on the North American version of the application and is hidden on the European 
versions. 


n 


si 
hi 


n 

s . 



M . 2.18.2 Validation 
ill No validation is necessary, 

2.18.3 Business Exceptions 
None have been identified at this time. 

2.18.4 System Exceptions 
None have been identified at this time. 

2.19 Vehicle Notes (Renter's Vehicle sub-screen! 

2.19.1 Behavior 

This is a free for m text field in wfr ^ th* m«r mav enter data. The information entered here is only visible 
from this screen. This field appears on all versions of the application. 

2.19.2 Validation 
No validation is necessary. 

2. 1 9. 3 Business Exceptions 
None have been identified at this time. 

2.19.4 System Exceptions 
None have been identified at this time. 


Confidential 


© Enterprise Rent-A-Car, 2001 


Page 20 


Rental Redesign 

Version: 2.7 

Supplementary Specification 

Date: 12/21/2001 

Vehicle / Shop 


2.20 Account Name (Shop su b-screen) 

2.20.1 Behavior 

This field's value is en tered when: 

• User enters the Account name. 

• User clicks the "down a rrow" button to the imme diate right an d selects an Account from the 
Branch Short list. 

• User enters a valid number in the Account Number field. That number's Account name value will 
then populate this field, 

• User clicks the "Search" button and selec ts an Account from the Account Information list. 

• User clicks the "Not on File" button and enters the appropriate new Account information. 

If an Account name is entered, the Account Number, Contact Name and Phone Number fields will then be 
populated. If the Account name is blanked out and the user tabs off or leaves the field, Account Number 
and Contact will also be blanked out. This field appears on all versions of the application. 

2.20.2 Validation 

No validation is necessary. 

2.20.3 Business Exceptions 

None have been identified at this time. 

220.4 System Exceptions 

None have been identified at this time. 

0 

2.21 Down aiTQW button (Sho p sub-screen! 

2.21.1 Behavior 

This will bring up the Branch Short list allow ing the user to select a specific Account. If in Europe, the 
European Branch Short list will be brought up. If an Account is selected, the Account Name, Account 
Number, Contact Name and Phone Number fields will then be populated. This button appears on all 
versions of the application. 

2.21.2 Vafidation 

No validation is necessary. 

2.21.3 Business Exceptions 

None have been identified at this time. 

2.21.4 System Exceptions 

None have been identified at this time. 

2.22 Account Num ber (Shop sub-screen) 

2.22.1 Behavior 

This field's value is entered when: 

• User enters a valid name in the Account Name field. That name's Account number value will then 
populate this field. 

• User clicks the "down arrow" button to the immediate left and selects an Account from the Branch 
Short list. 

• User enters the Account number. 

• User clicks the "Search" button and selects an Account from the Account Information list. 

• User clicks the "Not on File" button and enters the appropriate new Account information. 

If an Account number is entered, the Account Name, Contact Name and Phone Number fields will then be 
populated. If the Account number is blanked out and the user tabs off or leaves the field, Account Name 
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and Contact will also be blanked out. This field appears on all versions of the application^ 

2.22.2 Validation 

No validation is necessary. 

2.22.3 Business Exceptions 

None have been identified at this time. 

2.22.4 System Exceptions 

None have been identified at this time. 

2.23 Search button (Shop sub-screen) 

2.23.1 Behavior 

This will bring up the Account Search screen allowing the user to search for and then select a specific 
Account. If an Account is selected, the Account Name, Account Number, Contact Name and Phone 
Number fields will then be populated. This button appears on all versions of the application, 

2.23.2 Validation 

No validation is necessary. 

2. 23. 3 Business Exceptions 

None have been identified at this time. 

2.23.4 System Exceptions $ 
None have been identified at this time. 

2.24 Not on FHe button (Shop sub-screen) 

2.24.1 Behavior 

This will bring up the Add Account Not on File screen allowing the user to enter information for a new 
Account . After all the necessary fields on that screen are entered, the Account Name, Account Number, 
Contact Name and Phone Number fields will then be populated with that screen's entered information. This 
button appears on all versions of the application. 

2.24.2 Validation 

No validation is necessary. 

2.24.3 Business Exceptions 

None have been identified at this time. 

2.24.4 System Exceptions 

None have been identified at this time. 

2.25 Contact Na me (Shop sub-screen) 

2.25.1 Behavior 

This field's value is entered when: 

• User enters a valid name in the Account Name field. That name's Contact name value will then 
populate this field, 

• User clicks the "down arrow" button to the immediate right of Account Name and selects an 
Account from the Branch Short list. That Account's Contact name value will then populate this 
field's value. 

• User enters a valid number in the Account Number field. That number's Contact name value will 
then populate this field. 

• User clicks the "Search" button and selects an Account from the Account Information list. That 
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Account's Contact name value will then populate this field's value. 

• User clicks the 4C Not on File" butt on and enter s the appropriate new Contact inf ormation after the 
new Account inform ation. After all the necessary fields on that screen are entered, that screen's 
entered information for Contact name will then populate this field's value^ 

• User enters the Contact name. 

• User clicks the "down arrow** button to the immedi ate right and selects a Con tact from the Contact 
list 

• User clicks the "Add New" button and en ters the approp riate new Contact information. 
This field appears on all versions of the application. 

2.25.2 Validation 

No validation is necessary. 

2.25.3 Business Exceptions 

None have been identified at this time. 

2.25.4 System Exceptions 

None have been identified at this time. 

2.26 Down arrow button (Sh op sub-SCreenl 

2.26.1 Behavior 

This will bring up the Contact list allowing the user to select a specific Contact. If a Contact is selected, the 
Contact Name field will then be populated. This button appears on all versions of jhe application* 

2.26.2 Validation 

No validation is necessary. 

2.26.3 Business Exceptions 

None have been identified at this time. 

2.26.4 System Exceptions 

None have been identified at this time. 

2.27 New Contact button (Shoo sub-screen! 

2.27.1 Behavior 

This will bring up the New Contact screen allowing the user to enter information for a new Contact. After 
the necessary field on that screen is entered, the Contact Name field will then be populated with that 
screen's entered information. This button appears on all versions of the application* 

2.27.2 Validation 

No validation is necessary. 

2.27.3 Business Exceptions 

None have been identified at this time. 

2.27.4 System Exceptions 

None have been identified at this time, 

2.28 Phone Numb er (Shop sunscreen! 

2.28.1 Behavior 

This field's value is entered when: 

• User enters a valid name in the Account Name field. That name's Phone number value will then 
populate this field. 
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• User clicks the "down arrow" button to the immediate right of Account Name and selects an 
Account from the Branch Short list. That Account's Phone number value will then populate this 
field's value. 

• User enters a valid number in the Account Number field. That number's Phone number value will 
then populate this field. 

• User clicks the "Search" button and selects an Account from the Account Information list. That 
Account's Phone number value will then populate this field's value. 

• User clicks the "Not on File" button and enters the appropriate new Account information. That 
Account's Phone number value will then populate this field's value. 

• User enters the Phone number. 

This button ap pears on ail v ersions of the application. 

2.282 Validation 

No validation is necessary. 

2.28.3 Business Exceptions 

None have been identified at this time. 

2.28.4 System Exceptions 

None have been identified at this time. 

3. Not on File ( Figure 41 

3.1 Name * 

3.1.1 Behavior 

This is a text field in which the user ma v enter an Account name. 

3.12 Validation 

No validation is necessary. 

3. 1.3 Business Exceptions 

None have been identified at this time. 

3. 1. 4 System Exceptions 

None have been identified at this time. 

3.2 Address 

3.2.1 Behavior 

This is a free fo rm text field in which the user mav enter ? m Account's address. 

3.2.2 Validation 

No validation is necessary. 

3.2.3 Business Exceptions 

None have been identified at this time. 

3.2.4 System Exceptions 

None have been identified at this time. 

3.3 ZiB 

3.3.1 Behavior 
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3.3.2 Validation 

No validation is necessary. 

3. 3. 3 Business Exceptions 

None have been identified at this time. 

3.3.4 System Exceptions 

None have been identified at this time. 

3.4 Geographic Framework button (lightening bolt graphic) 

3.4.1 Behavior 

This will fill in the Citv and State fields if there is only 1 city for the zip code. If more than 1 city is in the 
gntered zip c ode, the Multiple Cities Found page will be brought up. allowing the user to select a citv. Tfa 
City and State fields will then be filled with the user's selection. 

3.4.2 Validation 

No validation is necessary. 

3. 4. 3 Business Exceptions 

None have been identified at this time. 

3.4.4 System Exceptions 

None have been identified at this time. 

3.5 Country 

3.5.1 Behavior 

This is a drop down field containing the list of countries. 

3.5.2 Validation 

No validation is necessary. 

3. 5.3 Business Exceptions 

None have been identified at this time. 

3. 5. 4 System Exceptions 

None have been identified at this time. 

3.6 Q&t 

3.6.1 Behavior 

This is a text field in which the user mav enter an Account's citv. This field mav also he filled bv actions 
performed bv the Geographic Framework button. 

3.6.2 Validation 

No validation is necessary. 

3.6.3 Business Exceptions 

None have been identified at this time. 

3. 6. 4 System Exceptions 

None have been identified at this time. 
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3.7 State 

3.7.1 Behavior 

This is a dro p down field containing the list of state s. This field mav also he filled hv actions performed by 

3.7.2 Validation 

No validation is necessary. 

3. 7. 3 Business Exceptions 

None have been identified at this time. 

3. 7.4 System Exceptions 

None have been identified at this time. 

3.8 Phone 

3.8.1 Behavior 

This is a text field in which the user mav enter an Account's phone number. 


P 3.8.2 


Entered data should be 10 digits for the US to include area code or the appropriate format for other 
IJ3 countries. 


2 3.8.3 Business Exceptions 

i ,1 None have been identified at this time. 

'■TV 

3.8.4 System Exceptions 

None have been identified at this time. 

Hi 


jsas. 


3.9 c-nnf art Last Name 

3.9,7 Behavior 

This is a text field in which the user m*v enter a Contact's name for the new Account. 

3.9.2 Validation 

No validation is necessary. 

3. 9. 3 Business Exceptions 

None have been identified at this time. 

3. 9. 4 System Exceptions 

None have been identified at this time. 

3.10 

3.10.1 Behavior 

Thk is * text field in which the user m*v enter a Contact's first name for the new Account. 

3.10.2 Validation 

No validation is necessary. 

3.10.3 Business Exceptions 

None have been identified at this time. 

3.10.4 System Exceptions 

None have been identified at this time. 
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3.11 Button Line Area - Add Account Not on File 

3.11.1 OK button 

3.11.1.1 Behavior 

If data is not present in the required fields the feedback m essage explain s that a value needs to be entered in 
the field(s) that is/are blank. T wo options are presented. OK and Cancel. OK take s the user back to the Add 
Account Not on File screen for data entry, Cancel dis misses the Add Account Not on File screen. 

3.11.1.2 Validation 

There must be data present in all fields except for Contact Last Name and First Name where only one needs 
to have data present 

3.11.13 Business Exceptions 

None have been identified at this time. 

3. 1 1 1 .4 System Exceptions 

None have been identified at this time. 

3.712 Cancel button 

3.112.1 Behavior 

This button will dismiss the Add Account Not on File screen without saving any data. 

3.112.2 Validation 

3.112.3 Business Exceptions 

None have been identified at this time. 

3.112.4 System Exceptions 

None have been identified at this time. 

4. New Contact (Figure 5^ 

4.1 Last Name 

4.1.1 Behavior 

This is a text field in which the user may enter a Contacts last name for an already selected Account. 

4.12 Validation 

No validation is necessary. 

4.1.3 Business Exceptions 

None have been identified at this time. 

4.1.4 System Exceptions 

None have been identified at this time. 

4.2 First Name 

4.2.1 Behavior 

This is a text field in which the user mav enter a Contact's first name for an already selected Account. 
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4.2.2 Validation 

No validation is necessary. 

4.2.3 Business Exceptions 

None have been identified at this time. 

4.2.4 System Exceptions 

None have been identified at this time. 

4.3 Button Line Area - New Contact 

4.3.1 OK button 

4.3.1.1 Behavior 

If data is not present in the Last Name and/or the First Name field(s), the feedback message explains that a 
value needs to be entered for Last Name and/or First Name. Two options are presented. OK and Cancel. 
OK takes the user back to the New Contact screen for data entry. Cancel dismisses the New Contact screen. 
OK will be the default selection. 

4.3.1.2 Validation 

There mus t be data present in Last Name_ and/or First Name field(s). 

4.3.1.3 Business Exceptions 

None have been identified at this time. 

4.3.1.4 System Exceptions 

None have been identified at this time. 

4.3.2 Cancel button 

4.3.2.1 Behavior 

4.3.2.2 Validation 

If data has be en entered the following feedback message is displayed: " Are vou s ure you want to exit and 
lose the entered information?". Two options are presented. Yes and No. Y es will dism iss the screen and not 
save the data. N o will take the user back to the New Co ntact screen. 
The default button selection is "No". 

4.3.2.3 Business Exceptions 

None have been identified at this time. 

4.3.2.4 System Exceptions 

None have been identified at this time. 

5. Rules 

5.1 Year r Make and Mode! domain values come from the database. 

5.2 A Contact m ust be selected for every Account that is selected as a Shoo. NOTE: This is 
not a requireme nt for Reservation. 

5.3 The system should not s earch for or d isplay any d^ctiv^t&d Accounts. 

5.4 User needs to have ability to cancel a search at anv time during the search. 

5.5 Notes should be generated when any of the following events occur: 
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6. Security 

The user must have the appropriate security level to access this screen. 


User adds a "Not 
on File" Shop 

Shop [Blank] was changed to "XXXX" 

Create/ 
Edit 

Create (if data exists from 
the reservation) /Edit 

Vehicle/Shop 

User adds a "Not 
on File" Shop 
Contact 

Not on File Contact "First Name Last Name" 
was added for Account "XXXXX" 

Create/ 
Edit 

Create (if data exists from 
the reservation) /Edit 

Vehicle/Shop 

User changes the 
Shop Account 

Shop "XXXX" was changed to "XXXX" 

Edit 

Create (if data exists from 
the reservation) /Edit 

Vehicle/Shop 

User changes the 
Type of Loss 

Type of Loss "XXXX" was changed to 
"XXXX" 

Edit 

Create (if data exists from 
the reservation) /Edit 

Vehicle/Shop 

User changes the 
"Total Loss?" 

Total Loss "XXXX" was changed to 
"XXXX". 

Edit 

Create (if data exists from 
the reservation) /Edit 

Vehicle/Shop 

User changes the 
Date of Loss 

Date of Loss "XXXXXX" was changed to 

"VYYYYY" 
AAAAAA 

Edit 

Create (if data exists from 
the reservation) /Edit 

Vehicle/Shop 

I Iser chauffer 
number of Theft 
Waiver Days 

Theft Waiver Davs "X" was changed to "X" 

Edit 

Create (if data exists from 
the reservation) /Edit 

Vehicle/Shop 
(North 
America) 

User changes the 
Registration 
Number 

Registration Number "XXXX" was changed 
to "XXXX" 

Edit 

Edit 

Vehicle/Shop 
(Ireland, UK, 
Germany) 

User changes the 
Class 

Class "XX" was changed to "XX" 

Edit 

Edit 

Vehicle/Shop 
(Germany) 

User changes the 
Renter's Vehicle's 
Year 

The Renter's Vehicle Year "XXXX" was 
changed to Year "XXXX" 

Edit 

Edit 

Vehicle/Shop 

User changes the 
Renter's Vehicle's 
Make 

The Renter's Vehicle Make "XXXX" was 
changed to Make "XXXX" 

Edit 

Edit 

Vehicle/Shop 

User changes the 
Renter's Vehicle's 
Model 

The Renter's Vehicle Model "XXXX" was 
changed to Model "XXXX" 

Edit 

Edit 

Vehicle/Shop 

User changes the 
Renter's Vehicle's 
Other Make 

The Renter's Vehicle Other Make "XXXX" 
was changed to "XXXX" 

Edit 

Edit 

Vehicle/Shop 

User changes the 
Renter's Vehicle's 
Other Model 

The Renter's Vehicle Other Model "XXXX" 
was changed to "XXXX" 

Edit 

Edit 

Vehicle/Shop 
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Supplemental Specification 

1. Reservation Print 

This document details out the print requirements for the Reservation sub-application. 


When the user selects anv of the print ooti nns. the system will display the IF print dialog box . The user 
must select OK tn initiate printing. There will be no Hot Kevs. and the system will automatically fire the 
OK hutton if the user hits the enter kev . 
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1.2 Reservation Searnh Screen 

1.2.1 Tha system displays the o ption for the user to: 

• Print Current Page 

• Print All Records 

1.2.2 Print Current Page 

This function prints the reco rds that are currently beino disnlaved on the screen. 

CNOTE: If the result set is b roken down into grou ps of 20 , this function will print the current set of 20 
records regardless if thev are all displayed on the screen.) 


01 

M 

S-8 3 


m 

3* T: 

m 


12.3 Print All Records 

This function prints all the records th at were returned 
1.2.4 Print Output 

The records when printed shnuld look like this for both o ptinns: Print Current Paoe and Print All Records, 
If the amount of records exceeds one page, the column headers should appear at the top of every page. 
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□ 


W 

S ..2 


III 
3M a 

iIj 



Reservation Search Results 


Records Found: 13 


v. -i 

*1 






Pickup 


Reservation 

Reservation 

GP/BR 

Pickup Date 

Pickup Time 

Renter Name 

Method 

Car Class 

Type 

Number 

1022 

02/28/2001 

8:30 AM 

Smith, Roger 

P/UP 

MVAR 

Retail 

103453 

1022 

03/01/2001 

8500 AM 

Tucker, James 

P/UP 

ECAR 

Insurance 

103029 

1022 

03/01/2001 

11:00 AM 

Smith, Robert 

W/IN 

FCAR 

Fleet 

Q345T1 

1022 

03/05/2001 

8i00 AM 

Verhoist, Laura 

DEL 

ECAR 


104439 

1022 

03/05/2001 

2;30 PM 

Stein, Amy 

W/IN 

STAR 

Retail 

104528 

9833 

03/02/2001 

11:45 AM 

Atteberry, James 



Retail 

1B2045 

9833 

03/15/2001 

5i00 PM 

Howard, Ron 

CWC 

FCAR 

Corporate 

454657 

9833 

04/11/2001 

8i45 AM 

Johnston, Johnny 

DEL/R 

FCAR 

Insurance 

BMW3ZR 

9844 

01/01/2001 






645RTQ 

9855 

02/02/2002 


This is a realiy long name 
used to show wrapping 

W/IN 



RE1234 

9866 

03/03/2003 






HDF22S 

9877 

04/04/2004 





i 

L33THG 

9888 

05/05/2005 






SCR177 


* ^ f 


V-l 


Si 
% 
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3 S S 


" 2 

5 ■ 

5 y 


1,3 Reservation Detail 

13.1 The system displa ys the option for the user to Print. This action prints the details of the 
Reservation 

ThP user ma y select the print option at anv tim s while creating, editing or viewing a reservation, 

1.3.2 Print (Reservation Detain 

This function prints the Reservation Detail. 

1.3.3 Print Output 

The record s when printed should l ook like this. 


vontes Tods Hep - * 


Reservation Details 


JOURIS^ON 
Reservation: SR2S47 


DELIVERY 

Date Taken: 09/19/01 


□9/27/01 

Byi Mary Schmitt 


10:30 AM 


FCAR 


Vehicle 

Car Class: 
Rate Quoted: 


Product/ Services: 


Preferences: 


FCAR 

25.99 dayj 150 miles a day; .25 excess mries 
295.99 week; 1050 miles a week; .25 excess miles 
985.00 month; 3000 miles a month; .25 excess miles 


CDW (Collision Damage Waiver) 
PAI (Personal Accident Insurance) 
Drop Fee 

RENTER STRONGLY PREFERS A 4-DOOR CHEVY MAUU, RED, THAT DOES NOT SMELL LIKE 
SMOKE, . 


15.00 per day 
2.00 per day 
10,00 


-Pick Up/Delivery 
Pick Up Date: 

September 27, 2001 

Directions: TAKE 40 TO THE SRENTWOOD EXIT. TURN 
LEFT ONTO BRENTWOOD. GO PAST 

Pick Up lime: 

10:30 AM 

CLAYTON, TAKE THE NEXT LEFT INTO 

Return Date: 

September 30, 2001 

CORPORATE PARK. PARK IN FRONT OF 
THE SECOND BUILDING (600 CORPORATE 

Return Time; 


PARK). 


Pick Up Method: 

Dehuery 



Pick Up Location! 

OFFICE 




r- Renter ~ 




JOURIS, JON 


Home: (314) 867-5309 


600 CORPORATE PARK 

Wo*: (314) 512-5000 


ST, LOUIS, MO 63105 




Rental Type: 

Insurance 

Primary Payment Method: 

Credit Card 

Bill To: 

FARMERS - ST. LOUIS 

Authorization Status: 

Authorized 


SUITE 201 

Daily Rate Authorized: 

25.99 


1234 INSURANCE ROAD 

Claim Type: 

Claimant 


CHESTERFIELD, 63017 MO 



Contact: 

JOHN DOE 

Claim#/P0#/R0#: 

Claim* 123456 

Shop: 

JOE'S AUTOBODY 
12633 MANCHESTER RD 
MANCHESTER, MO 63021 

Renter's Vehicle: 

1998 Cheverolet Maitbu 


I. 


?• V 


i 


"vti 

?v ■ 

'I 
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1.4 Reservation List Report Screen 

1.4.1 The system displays the op tion for the user to Print List: 

1.4.2 Print List 

This function nrints the list that is current ly displayed to the user. 

1.4.3 Print Output 

The records w hen printed should look like the print below. 


i? 2 

u 

m 

3 



Group: 01 
Date: 05/09/2001 


Reservation List 

Branch: All 


Records Found: 13 


•8 


GP/BR Pickup Date 

Pickup 

Time 

Renter Name 

Pickup 

Method Pickup Location 

Car 
Class 

Preference 

Reservation 
Type 

1022 

02/28/2001 

8:30 AM 

Smith, Roger 

P/UP Airport 

MVAR 


Retail 

1022 

03/01/2001 

8:00 AM 

Tucker, James 

P/UP Office 

ECAR 


Insurance 

1022 

03/01/2001 

11; 00 AM 

Smith, Robert 

W/IN 

FCAR 


Fleet 

1022 

03/05/2001 

8:00 AM 

Verhoist, Laura 

DEL 

ECAR 



1022 

03/05/2001 

2:30 PM 

Stein, Amy 

W/IN 

STAR 


Retail 

0133 

03/02/2001 

11} 45 AM 

Atkeberry, James 




Retatl 

0133 

03/15/2001 

5:00 PM 

Howard, Ron 

cwc 

FCAR 

2dr car with 
performance 

Corporate 

0133 

04/11/2001 

8:45 AM 

Johnston, Johnny 

DEL/R At the corner of 
5th and Main 

FCAR 


Insurance 

0144 

01/01/2001 







\ 0155 

02/02/2002 


This is a really 
long name used to 
show wrapping 

W/IN 




0166 

03/03/2003 







0177 

04/04/2004 







0198 

05/05/2005 








SI 
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1.5 Reservation Summary Screen 

1.5.1 The system displays the option for the u ser tn Print Summary 

1.5.2 Print Summary 

This function p rints the table that is currently displayed to the user. 

1.5.3 Print Output 

The records when printed should loo k the print below. 
15.4 Special Req uirements 

The list should always start with the No Time row and end with the No Date row. In between are the 
individual time slot rows. The time should start with the branch o pen time, or the time of the first 
reservation, which ever is earlier. The time shou ld end with the branch close time T or the time of the last 
reservation, which ever is later. 



Reservation Summary 

Group: 01 Branch: 10 
j Date: 05/09/2001 

i 


... -Pickup 




NoTifiM* f 

5 







7:0* m> 

2 






LCAR, ICAR : 

7:30,^| 

3 






SCAR (3) 

8:00 AM 

3 






CCAR, SCAR(2), LCAR 


1 






SCAR 

9:00 

8 






ECAR(3), CCAR (2), ICAR, SCAR (2), LC 

9:30 ^ 

3 






CCAR, PCAR, LCAR : 

[ 10:00 AM 

8 

1 





ECAR, CCAR (3), ICAR (3) 

| 10:3d;p* 

5 






ECAR, CCAR(2), ICAR, FCAR 

1 11:00 J^; 

0 







t H:30^ 

2 






CCAR, FCAR 


1 






ECAR 









V:'--, 
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2:0ti£Ml? 


2:30^ 


T 


ECAR, CCAR 


SCAR 


CCAR (3), ICAR 


3t3(MW\ 


5:00 PM I 


5:30I?M 


CCAR 


ECAR, CCAR, SCAR, FCAR 


ICAR, SCAR, FCAR, MVAR 


CCAR, ICAR, FCAR (2), MVAR 
CCAR (2), FCAR, MVAR 


ECAR, CCAR, ICAR, FCAR, XPAR 
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1.6 Renter Search 


n i 
01 

las? 
a. 


s::a: s 

Q 

Li 


1.6.1 Print Current Page 

This function prints the records that are currently being displayed on the screen. 

(NOTE: If the result set is broken down into groups of 20, this function will print the current set of 20 
records regardless if they are all displayed on the screen.) 

1.6.2 Print All Records 

This function prints all the records that were returned from a search. 

1.6.3 Print Output 

The records when printed should look like this for both options: Print Current Page and Print All Records. 
If the amount of records exceeds one page, the column headers should appear at the top of every page. 



Renter Search Results 


Name 


Address 


Phone Number 


Atteberry, James 


2002 Mateus Apt B, Maryland Heights (444) 444-4444 (H) 

(314) 512-3479 (W) 


Date of Birth 

11/20/1971 


Jenson, George 


Bond, James 


Classified, Unknown 


Doe, Jane 


123 West Main, Anywhere 


1/2/1943 


5 Spacely, Apt 4, Sprockets 


(213) 547-4798 ext 45673(W) 
(541) 789-1234 (O) 


Lobochecski, Steve 


Mathews, Mike 


Pujols, Albert 


Sattaiuri, Chakravarfchy 


Smith, Ozzie 


Vina, Fernando 


Records Found: 10 


r4i 


■4 
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1 .7 Employee Search 

1.7.1 Print Current Page 

This function prints the records that are currently being displayed on the screen. 

(NOTE: If the result set is broken down into groups of 20, this function will print the current set of 20 
records regardless if they are all displayed on the screen.) 

1.7.2 Print All Records 

This function prints all the records that were returned from a search. 

1.7.3 Print Output 

The records when printed should look like this for both options: Print Current Page and Print All Records. 
If the amount of records exceeds one page, the column headers should appear at the tofjofevery page. 


^Employee Search fcesuits - Microsoft Internet Explorer provided bp Enterprise Rent-a-Car _ ' 


Employee Search Results 


Name 

Number 

Group /Branch 


Department 



Adams, Edward 

1234S 

0101 - 

Group Name - 

Branch Name 

D/R 

BRANCH MANAGER 


Adams, Mark 

23456 

0202 - 

Group Name - 

Branch Name 

MIS 

BUSINESS ANALYST II 


Adkins, Cindy 

34567 

0303 - 

Group Name - 

Branch Name 

USED CAR 

DETAILER 


Anne, Susan 

46739 

0404 - 

Group Name - 

Branch Name 

ADMIN 

DEPARTMENT 
MANAGER 

i 

Alagappiranar, 
Seenivasan 

37954 

0505 - 

Group Name - 

Branch Name 

NAT RES 

BRANCH MANAGER. 

w 

Atbers, Jeri 

5641-3 

0606 - 

Group Name - 

Branch Name 

D/R 

BUSINESS ANALYST II 


Allen, Karen 

6547E 

0707 - 

Group Name - 

Branch Name 

MIS 

DETAILER 


Alyes, Pam 

6542D 

0101 - 

Group Name - 

Branch Name 

USED CAR 

DEPARTMENT 
MANAGER 


Anantharam, 
Parasuram 

6546F 

0202 - 

Group Name - 

Branch Name 

ADMIN 

BRANCH MANAGER 


Andrews, Kurt 

1657F 

0303 - 

Group Name - 

Branch Name 

NAT RES 

BUSINESS ANALYST II 

v-o 
l/» \ 

Bagby, Dawn 

5456E 

0404 ■ 

• Group Name - 

Branch Name 

D/R 

DETAILER 

X 4 ! 

Bagby, James 

546SQ 

0505 • 

■ Group Name • 

■ Branch Name 

MIS 

DEPARTMENT 
MANAGER 


Bankston, Mary 

24352 

0606 • 

• Group Name * 

• Branch Name 

USED CAR 

BRANCH MANAGER 

1 

Baron, Bill 

4564F 

0707 

- Group Name - Branch Name 

ADMIN 

BUSINESS ANALYST II 


Bates, Chris 

57465 

0101 

- Group Name - Branch Name 

NAT RES 

DETAILER 


Bjornson, John 

6757J 

0202 

- Group Name 

- Branch Name 

D/R 

DEPARTMENT 
MANAGER 

<■ *. 

Blank, Shannon 

43654 

0303 

- Group Name 

- Branch Name 

MIS 

BRANCH MANAGER 


Chinautt, Sharon 

67830 

0404 

- Group Name 

- Branch Name 

USED CAR 

BUSINESS ANALYST II 


demons, Brad 

3245S 

0505 

- Group Name 

- Branch Name 

ADMIN 

DETAILER 


Coie, Scott 

2435R 

0606 

- Group Name 

- Branch Name 

NAT RES 

DEPARTMENT 
MANAGER 

>\\ 

Concannon, Maribeth 

3456U 

0707 

- Group Name 

- Branch Name 

MLB 

CARDS FAN 

% 

Cooley, Tracey 

34532J 

0808 

- Group Name 

- Branch Name 

MIS 

SYSTEMS ANALYST 


m 


Records Found: 23 
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1.8 Account Search 

1.8.1 Print Current Page 

This function prints the records that are currently being displayed on the screen. 

(NOTE: If the result set is broken down into groups of 20, this function will print the current set of 20 
records regardless if they are a!! displayed on the screen.) 

1.8.2 Print All Records 

This function prints all the records that were returned from a search. 

1.8.3 Print Output 

The records when printed should look like this for both options: Print Current Page and Print All Records. 
If the amount of records exceeds one page, the column headers should appear at the top of every page. 



Account Search Results 



Name 

Number 

Type 

Owning Address 
Gp/Br 

City 

State Zip Phone Number 


A Collector's 
i Bookstore** 

GE1658 

Corporate 

0101 

6275 Delmar 

St Louis 

MO 

63130 (314) 721-6127 


; A.f,j. Remodeling 

: CO** 

GE1225 

Corporate 

0102 

312 Oak Pk, Village 
Dr. 

Wildwood 

MO 

63040 (636) 458-1552 


Accent Lincoln- 
mercury** 

129498 

Dealership 

0103 

9700 Manchester Rd 

St Louts 

MO 

63119 (314) 968-5300 

i 

Advantage 
Decorating** 

GE0853 

Corporate 

0104 

1601 North 7th St. 

St, Louis 

MO 

63102 (314) 436-1419 


African Amer, Rite 
Of Passage** 

GE1538 

Corporate 

0105 

325 Debaliviere 

St. Louis 

MO 

63112 (314) 361-2268 


; Ahzad Bogosian** 

GE0830 

Corporate 

0106 

7743 Arthur 

St, Louis 

MO 

63117 (314) 645-3076 


Aig-cs** 

GE0238 

Corporate 

0107 

120 S Central, Ste 
300 

St Louis 

MO 

63105 (000) 000-0000 


Al-pac, Inc.** 

GE1350 

Corporate 

0108 

18535 Old Hwy 66 

Pacific 

MO 

63069 (636) 271-8222 


Aibertin Auto Body 
Inc** 

GGS868 

Bodyshop 

0109 

8449 Page 

St Louis 

MO 

63130 (314) 423-9924 


Allen*lynette* 

E75477 

Employee 

0110 

600 Glen Addie 

Shiloh 

IL 

62221 f314) 863-0055 











*s * 


v ?■ 
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Central Auto Body** 

129765 

Bodyshop 

0107 

3130 So. Big Bend 

St. Louis 

MO 


Central Realty** 

G15825 

Corporate 

0108 

15a North Meramec 
Ave 

St. Louis 

MO 

63105 (314) 862-5557 

Christ Memorial 
Baptist Church** 

GE1214 

Corporate 

0109 

206 Emerling Drive 

St, Louis 

MO 

63121 (314) 521-1958 

Christ Memorial 
Lutheran Youth** 

GE1093 

Corporate 

0110 

9712 Tesson Ferry 
Road 

St Louis 

MO 

63123 (314) 631-0304 

Christopher 
Desiiets, Attorney** 

GE2351 

Corporate 

0101 

6556 Mardel Ave 

St Louts 

MO 

63109 (314) 646-0715 

Chubb Grp-st 
Louis** 

CHB0101 

Insurance 

0102 

7733 Forsyth Suite 
1300 

St. Louis 

MO 

63105 (314) 863-6519 

Church Of The 
Shepard** 

01AG299 

Corporate 

0103 

4116 Mcday Rd 

St charles 

MO 

63304 (314) 441-6765 

Churchill School** 

G13242 

Corporate 

0104 

1035 Price School Ln. 

St Louis 

MO 

63124 (314) 997-4343 

City Of St. Louis- 
parks Dept** 

<3E1238 

Corporate 

0105 

3600 Clayton Ave- 
forest Park 

St Louis 

MO 

63110 (314) 289-5310 

Classic 
Refinishers** 

129469 

Other 

0106 

3714 Holt 

St. Louis, 

MO 

63116 (314) 773-7548 

Clayton Chamber Of GE9999 
Commerce** 

Corporate 

0107 

777 Bonhomme 

St Louis 

MO 

63105 (000) 000-0000 


4 


1 * - 

; 0 


Records Found: 23 
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1.9 Reservation Notes 

1.9.1 The system displays the option for the user to: 

• Print All Records 

• Print Note 

1 -9-2 Print All Records 
This function prints all the notes. 

1.9.3 Print Note 

This function prints the not e that is currently being displayed nn the screen. 

1.9.4 Print Output 

When all the records when are printed , the output should look like this: 



Reservation Notes for 456789 

Renter Name: John Doe * 


Date 

Time 

Note 

Status 

Note Type 

Created By 

ARMS Msg 

09/11/2001 

2:28 

PM 

PROTOTYPE CREATED FOR 
RESERVATION NOTES PRINT. 

Close 

System 

ECARS 2.0 User 


07/03/2001 

3:22 

PM 

CAR IS AT JOE'S <3ARA<3E 

Close 

Callback 

ECARS 2.0 User 





DOES NOT LIKE RED CARS. THIS 





07/02/2001 

2:22 

PM 

SHOWS THE FIRST TWO LINES OF 
THE NOTES SECTION (2 @ 45 

Open 

System 

System 

Sent 




CHAR). 





07/01/2001 

1:22 

PM 

RESERVATION CREATED 

Reservation 

System 

System 

Sent 






Records found 

: 4 








V 
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When an individual note is 


nit should look like this: 


5 Mote details - Microsoft Igicrnctj^ 


Reservation Note Details 


Renter: 

Christopher Smith 

Status: 
Open 

Note Type: 

System 


Reservation: 

456789 

Date Note Created: 

09/11/2001 

Time Note Created: 

3:05 PM 

Note Text: 

PREFERS A RED CAR WITH TINTED WINDOWS AND A SUNROOF. THIS SHOWS THE ABILITY OF THE SYSTeM rt T^ tt H T ^!: E 
A LONG NOTE. IT ALSO SHOWS THE BASIC LAYOUT OF THE NOTE WHEN THE DETAILS OF A SINGLE NOTE ARE PRINTED. 


Created By: 

ECARS 2.0 User 

ARMS Msg: 

Sent 
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1.10 Reservation Retro (NOT part of the pilot release) 


1 .10.1 The system displays the option for the user to print a Reservation Retro statement. This action 
prints the details of the Reservation in a Retro format. 

1.10.2 Print (Reservation Retro). This function prints the Reservation Retro. 

1 . 1 0.3 Print Output. The records when printed should look like this. 


^Reservation Retro - Microsoft: Internet Explorer provided by Enterprise Rent-a-Car 







m 



i ■<fefifesi:|® Y:V*PPS\Ecars 20\Development Projects\HTML\Reservation\ReservationPrlnHng\ResRetro.html*] jj 

— * — ' — ' r " " — ' — TJ 


ARMS Identification 


HOURIS, JOISI 
Reservation: SR2547 


DELIVERY 

Date Taken: 09/19/01 


09/27/01 

By: Mary Schmitz 


10:30 AM FCAR 
Referral Source: Referral 


r Vehicle 

Car Class: 
Rate Source: 
Rate Plan: 
Rate Quoted: 


FCAR 

Rate Source 
Rate Plan 

$25.99 day; 150 miles a day; ,25 excess miles 
$295.99 week; 1050 miles a week; .25 excess miles 
$985.00 month; 3000 miles a month; .25 excess miles 
Product/Services: CDW (Collision Damage Waiver) $15.00 per day 
PAI (Personal Accident Insurance) $2. 00 per day 
Drop Fee $10-00 


Preferences: Renter strongly prefers a 4- 
door Chevy Malibu, Red, that 
does not smell like smoke. 


{-Pick Up /Delivery- 
Pick Up Date: 
Pick Up Time: 
Pick Up Method: 
Pick Up Location: 
Return Date: 
Return Time: 
Return Method: 
Return Location: 


September 27, 2001 
10s30 AM 
Delivery 
OFFICE 

September 30, 2001 
4:30 PM 
Drop Off 
DEALER 


Directions: TAKE 40 TO THE BRENTWOOD EXIT. TURN 
LEFT ONTO BRENTWOOD. 
GO PAST CLAYTON, TAKE THE NEXT LEFT 
INTO CORPORATE PARK. 
PARK IN FRONT OF THE SECOND BUILDING 
(600 CORPORATE PARK). 


r Renter Information — 

JOURIS, JON 

600 CORPORATE PARK 

CLAYTON, MO 63105 


Home: (314) 867-5309 
Work: (314) 512-5000 
Other: (636) 274-8265 


Rental Type: 
Status of D-BiR: 
Bill To: 


Contact: 
Shop: 


Insurance 
In Limbo 

FARMERS - ST. LOUIS 
SUITE 201 

1234 INSURANCE ROAD 
CHESTERFIELD, 63017 MO 
(636) 237-2385 
JOHN DOE 
JOE'S AUTOBODY 
12633 MANCHESTER RD 
MANCHESTER, MO 63021 
(636) 773-9912 


Customer Payment Method: Cre dit Card 


Authorization Status: 
Daily Rate Authorized: 
Claim Type: 


Claim#/PO#/RO#: 
Renter's Vehicle: 


Authorised 

25.99 + tax/surcharge 
Claimant 


Claim* 123456 

1998 Cheverolet Malibu 


Disclosures — 

Disclosure statements will go here. 


r, 


Special Instructions 

Special Instructions will go here, 


V- 1 


g Local Wranet: 
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Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the Reservation Search screen, 
and its related screens. 


The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 

2. Simple Search 
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3 Reservation Search Criteria - Basic - Microsoft* Internet Explorer provided by Enterprise ftenf-o -Car 


Detail 


Summary Forecasting Notification j Search 



Reservation Search 


Group: 


Branch: 


1 01 - St. Louis 


The First Branch 


Advanced Search 


Renter Last Name: 


Renter First Name: 


Renter Telephone Number: 


Reservation Number: 



mifndam Date * V£ " 

Pickup Tim* ' 




^VResewafiiro^ 

Number * 

1022 

02/28/01 

8i30 AM 

Smith, Roqer 

Pick-Up 

MVAR 

Retail 

103453 


1022 

03/01/01 

8:00 AM 

Tucker. James 

Pick-Up 

ECAR 

Insurance 

103029 


1022 

03/01/01 

lliOO AM 

Smith, Robert 

Walk-In 

FCAR 

Fleet 

Q.345T1 : 

1 


Items 1 - 10 of 50 found 


Prev 1 2 3 4 5 Next 


Tsar 


Tkt - 234567 Cbk - 363221 


Figure 1 - Simple Search 
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^Reservation S earch Criteria - Basic- - Microsoft Internet Explorer provided by Enterprise Renl-arGaf 



Detail [ Summary | Forecasting [ Notification | Search 


Reservation Search 


Group: 

1 01 - St. Louis' 


Branch: 


The First Branch 


Advanced Search 


Renter Last Name: 


Renter First Name: 


Renter Telephone Number: 


Reservation Number: 



Items 1 - 10 of 50 found 


Prev 12 3 4 5 Next 


■ 


' - A 



Figure 1.1- Simple Search - Reservation Pilot version 
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3. Advanced Search 
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8 Pickup Date From: 


hi 


£3 

Id 


Forecasting | Notification I Search 


Reservation Search 


Group: 

1 01 -St. Louis' 


Branch: 

[The First Branch 


Simple Search 


Renter Last Name: 


Renter First Name: 


Renter Telephone Number: 


Reservation Number: 


-Bill-To and Shop Customers 

© Account Name: C 1 Customer Number: 


To: 


Claim/Policy/P.O. Number: 


Date Reservation Taken: 


(MM/DD/YYYY) 


(MM/DD/YYYY) 


(MM/DD/YYYY) 



1022 

02/28/01 

8:30 AM 

Smrth, Roqer 

P/UP 

MVAR 

Retail 

103453 

1022 

03/01/01 

8:00 AM 

Tucker> James 

P/UP 

ECAR 

Insurance 

103029 

1022 

03/01/01 

1 liOO AM 

Smith, Robert 

W/IN 

FCAR 

Fleel 

Q345TI 

1022 

03/05/01 

8:00 AM 

Verhoist^ Laura 

DEL 

ECAR 


104439 










Items 1 - 10 of 50 found 


Prev 12 3 4 5 Next 


Res - 411781 


Tkt - 234567 


Cbk - 363221 


Figure 2 - Advanced Search 
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h 

Is* 
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1 « 
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s, 5 J 
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s K g 


3^Reservcition ^Search Dfteriap'l^^^.ced - >4ictt«oft Internet E^iofetrprowded: by Enterprise. R'ent-a'-Gar 'r^I^MM 




Hi i i Bill 


Detail 


Summary [ Forecasting [ Notification | Search 


Reservation Search 


Group: 

1 01 - St Louis' 


Branch: 


Simole Search 


Renter Last Name: 


[ 


Renter First Name: 

I j 


Renter Telephone Number: 


Reservation Number: 


pBill-To and Shop Customers 

© Account Name: C Customer Number: 


j 


Claim/Policy/P.O. Number: 


Pickup Date From: 


To: 


Date Reservation Taken: 


Renter's License Plate: 


(MM/DD/YYYY) 


(MM/DD/YYYY) 


(MM/DD/YYYY) 



1022 

02/28/01 

8; 30 AM 

Smithy Roqer 

P/UP 

MVAR 

Retail 

103453 | 

1022 

03/01/01 

8; 00 AM 

Tucker James 

P/UP 

ECAR 

Insurance 

103029 

1022 

03/01/01 

11:00 AM 

Smith, Robert 

W/IN 

FCAR 

Fleet 

Q345T1 

1022 

03/0 5/0 1 

8:00 AM 

Verhoisti Laura 

DEL 

ECAR 


104439 





•.I • 





Items 1 - 10 of 50 found 



Prev 12 3 4 5 Next 


1 


Tkt - 234567 Cbk - 363221 


rnnSSTi.Ta.'ag.- 


J3; 


Figure 2.1- Advanced Search - Reservation Pilot version 



Su 

Mo 

Tu We Th 

Fr 

Sa 

1 

a 

1 4 5 

6 

2 i 

8 

9 

10 11 12 

13 

14 j 

15 

16 

17 18 19 

20 

21 

! 22 

23 

24 25 26 

27 

28 i 

i 29 

i 

! 

30 

Cancel 




I . , ■ ■ ■ . 

Figure 3 - Calendar selection 
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4. Group 

4.1 Behavior 

This search criterion will be limited to those groups that exist at any point in time for which the search is 
being executed. The selection of "All" is also included, and will appear at the top, or first, in the list. This 
search criteria area will be a drop-down box. The users would also like to have the ability to type a 
character, alpha or numeric, into the criteria area and have the drop down list position to the character. (If 
the user enters an "H" the drop down list would position to the first string beginning with "H" in the list) 
The default item should be the group associated to the terminal locale. 

For Reservation Pilot only, this box will default to the location's group, and cannot be changed. 

4.2 Validation 

The items appearing in the list are static; the user cannot add items to the list dynamically. This should, in 
some manner, be initially defaulted to the terminal's group, (based on physical location) 

4.3 Business Exceptions 

None identified at this time. 

4.4 System Exceptions 

None identified at this time. 

5. Branch * 

5.1 Behavior 

This search criterion will be limited to those branches that exist within the group at any point in time for 
which the search is being executed. The selection of "All" is also included, and will appear at the top, or 
first, in the list. This search criteria area will be a drop-down box. The users would also like to have the 
ability to type a character, alpha or numeric, into the criteria area and have the drop down list position to 
the character. (If the user enters an "H" the drop down list would position to the first string beginning with 
"H" in the list) 

The default item should be the branch associated to the terminal locale. Branch items appearing in the list 
will be limited to die Group item selected. Once the selected Group item has changed, the first item (All) 
will be the default selection item. 

5.2 Validation 

The items appearing in the list are static; the user cannot add items to the list dynamically. This should, in 
some manner, be initially defaulted to the terminal's branch, (based on physical location). 
This list will be limited to the branches associated with the group selected. 

5.3 Business Exceptions 

None identified at this time. 

5.4 System Exceptions 

None identified at this time. 

6. Renter Name Last / First 
6.1 Behavior 

This search criteria area will be a text field containing an implied wildcard after the entered criteria. The 
First Name field will not be enabled until search criteria has been entered into the Last Name field. Thus, 
the First Name field will not be accessible via either the tab key or the mouse unless Last Name data is 
present. 

It should be noted that either Last Name or Last Name and First Name used in combination, is 
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considered to be just one search criteria. 

It will return exact matches for the characters entered and will continue with other text strings that match 
the characters entered, but are of a longer length (an implied wildcard). Example: If the Last Name search 
criteria entered were "Smith", you would receive back every open ticket with "Smith" in the Last name. 
You would also receive every character string that matched "Smith" for the first 5 characters, but was 
longer than five characters. Given this, you would also receive, "Smither", "Smithson", "Smithy", etc. 
These longer character matches would be alphabetically ascending after the exact character matches of 
equal length. The First Name field behaves in the same manner. 

6.2 Validation 

Limited to, or constrained by, the Group and Branch indicated or selected. 

6.3 Business Exceptions 

None identified at this time. 

6.4 System Exceptions 

None identified at this time. 

7. Renter Telephone Number 

7.1 Behavior 

This search criteria area will be an alphanumeric field. It will not be formatted for presentation purposes. 
Returns exact matches for the characters entered. A phone number is consideredto be the entire number 
including area code. Example: In the United States, it would be the 3 digit area code, plus the seven digit 
phone number, (Country Code is not considered a part of the phone number.) The search will be on all 
phone number fields associated with the Driver/Renter. Currently, these are Home, Office and Other. If the 
same phone number is found in multiple areas for the same reservation, the reservation will only be 
displayed once. 

7.2 Validation 

Limited to, or constrained by, the Group and Branch indicated or selected. 

7.3 Business Exceptions 

None identified at this time. 

7.4 System Exceptions 

None identified at this time. 

8. Reservation Number 

8.1 Behavior 

This search area will be an alphanumeric field. It will return exact matches for the characters entered. 
When this search criterion is used, any other entered criteria will be ignored by the system. Alphanumeric 
values will be accepted into this field. 

For Reservation Pilot only, the search will be limited to the location's group. All other search criteria will 
be ignored. 

8.2 Validation 

Any entry into this field constitutes a global search of all groups and branches. It will override the default, 
or selected, group and branch. 

8.3 Business Exceptions 

None identified at this time. 
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8.4 System Exceptions 

None identified at this time. 

9. Account Name 

9.1 Behavior 

This search criteria area will be a text field with an implied wild card search after the last character. There 
is a radial button associated with this criteria area. Upon initial entry, the button will default to Account 
Name. 

It will return exact matches for the characters entered and will continue with other text strings that match 
the characters entered, but are of a longer length. 

An entry into this field will search two roles that a customer may be and return all matches. Currently, the 
roles to which the number search may be applied are "Shop" and "Bill-To". 

9.2 Validation 

Limited to, or constrained by, the Group and Branch indicated or selected. 

9.3 Business Exceptions 

The user may not select the Account Name and the Customer Number Radial button. The two are mutually 
exclusive. 

9.4 System Exceptions 

The system prohibits selecting both buttons. It must be one or the other. t 

1 0. Customer Number 

10.1 Behavior 

This search criteria area will be an alphanumeric field. 

There is a radial button associated with this criteria area. Upon initial entry, the button will default to 
Account Name. This radial button can be switched to initiate a customer number search when the user 
selects the Customer number radial button. 

It will return exact matches for the characters entered. An entry into this field will search two roles that a 
customer may be and return all matches. Currently, the roles to which the number search may be applied 
are "Shop" and "Bill-To". 

10.2 Validation 

Limited to, or constrained by, the Group and Branch indicated or selected. 

10.3 Business Exceptions 

The user may not select the Account Name and the Customer Number Radial button. The two are mutually 
exclusive. 

10.4 System Exceptions 

The system prohibits selecting both buttons. It must be one or the other. 

1 1 . Claim/Policy/P.O./R.O. Number 

11.1 Behavior 

This search criteria area will be an alphanumeric field. It will return exact matches for the characters 
entered. 

11.2 Validation 

Limited to, or constrained by, the Group and Branch indicated or selected. 
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1 1 .3 Business Exceptions 

None identified at this time. 

1 1 .4 System Exceptions 

None identified at this time. 

12. Range of Pick-Up Dates 

12.1 Behavior 

This search criteria area will be two numeric fields. A "From" and a "To" area are anticipated. Also, 
associated with each field, there should be some sort of calendar function available which would allow the 
user to select a date from a calendar icon, or similar feature, instead of entering a value. If the user selects a 
date from the calendar icons, it will be displayed in the date area formatted appropriately by the locale. (As 
determined for all locale specific formatting.) All of the From/To conditionals will still apply, if the date(s) 
are selected from this calendar feature. The range of dates which may be searched (in the future and past) 
Mil be dependent on the legacy systeik and the range of data stored there. It needs to be understood, that 
legacy system may have different retention rules than the GUI system. 

Whether the user enters just a From date, or both From and To date, it is considered a single search 
criteria. 

12.2 Validation 

From search criteria area. 

Alphanumeric values will be accepted into this area. 
It will not be formatted for presentation purposes. 

The user may enter delineating characters, but these will be stripped out before searching the 
database to find an exact date match. 

It will be the date appropriate to the locale of the branch where the pick-up of the vehicle is 
expected. 
To search criteria area: 

Alphanumeric values will be accepted into this area. 
It will not be formatted for presentation purposes. 

The user may enter delineating characters, but these will be stripped out before searching the 
database to find an exact date match. 

This area is not enabled until an entry has been made into the From area. 

If there is no entry into the From area the To area remains disabled. 

It will be the date appropriate to the locale of the branch where the pick-up of the vehicle is 

expected. 

12.3 Business Exceptions 

FROM - None identified at this time. 

TO - If the user does not enter a value into the To field, it will default to the same value as the 
From field. If the user enters a value into the second field, the To field, it must be greater than, or 
equal to the value in the first field, the From field. 

12.4 System Exceptions 

FROM - None identified at this time. 

TO - The system would provide an error message. See the "error message" supplemental spec for 
exact text." 


Confidential 


©<Company Name>, 2000 


Page 15 


<Project Name> 

Version: <1.0> 

Supplementary Specification 

Date: <dd/mmrn/yy> 

<docurnent identified 


13. Date Reservation Taken 

13.1 Behavior 

This search criteria area will be an alphanumeric field. It will not be formatted for presentation purposes. 
The user may enter delineating characters, but these will be stripped out before searching the database to 
find an exact date match. 

It will be the date appropriate to the locale of the branch where the reservation was created. 

13.2 Validation 

It cannot be for a date in the future. 

13.3 Business Exceptions 

The system would provide an error message. See the "error message" supplemental spec for exact text. 

1 3.4 System Exceptions 

None identified at this time. 

1 4. Renter's License Plate 

14.1 Behavior 

This search criteria area will be an alphanumeric field. It will return exact matches for the characters 
entered. This field will not appear if the screen is displayed with a US or Canada locale. 

14.2 Validation * 

Limited to, or constrained by, the Group and Branch indicated or selected. 

14.3 Business Exceptions 

None identified at this time. 

14.4 System Exceptions 

None identified at this time. 

15. Advanced Search / Simple Search hyperlink 

15.1 Behavior 

By clicking on the Advanced Search hyperlink, the user is presented with the advanced search functionality 
Alternatively, by clicking on the Simple Search hyperlink, the user is presented with the default search 
screen. Any search criteria entered when on the default Simple Search screen will be passed to the 
Advanced Search screen iffwhen accessed. If the user navigates to the Simple Search screen from the 
Advanced Search screen, any search criteria shared by both screens will be passed to the Simple Screen. 
Any search criteria valid only on the Advanced Screen be lost. 

15.2 Validation 

Must have at least one search criteria entered, not considering Group and Branch. 

15.3 Business Exceptions 

An error message stating the "A minimum of at least one search criteria must be entered" should be 
presented to the user. 

15.4 System Exceptions 

None identified at this time. 
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16. Results Display Area 
16.1 Behavior 

The result display will initially be blank on first presentation of the panel and until at least one search is 
executed and at least one record is found that matches the search criteria. 


This display area provides the user with the search result list. The result list will be comprised of 8 static 
columns. The specific column order is: 

1 ) The group number and branch number will be concatenated to form this column. 

2) The pick up date is the next column, formatted by locale. 

3) The pick up time is the next column, formatted by locale. 

4) The renter's last name and first name will be concatenated to form this column. 

5) The pick-up method. 

6) The car class. 

7) The reservation type. 

8) The reservation number. 


The display presentation for each type of information will adhere to result list standards. 
The default sort order is: 

1) Pick-up group and branch, in numeric ascending order. 

2) Pick-up date, in chronologically in ascending order. 

3) Pick-up time, in chronologically ascending order. $ 

4) Renter last and first name, in alphabetically ascending order of last name. 


The users would like to have the ability to sort the columns in both ascending and descending order. This 
will only sort the information displayed on the panel and not the entire result set If the user selects to sort 
the display by a column, the default sort order will be the order of the remaining sorts, if the user chooses to 
sort on a column that is not included in the default sort order. If the user moves forward or backward 
within the result list, the sort on re-presentation of the list is the default sort. The user must select to sort on 
a specific column within the new display if they want a sort order other than the default. 

The capability also needs to exist where a user can indicate or select an individual reservation from the 
result list, and perform a simple task, (a function button, icon, mouse click) which would then open the - 
reservation for editing purposes. Within this display list the user would select the Renter Name from the 
display list and perform the designated function. This would be contingent upon the user having the 
appropriate security to edit the reservation selected. This functionality will be consistent and standard 
throughout the application. 


16.2 Validation 

The user may not select to edit a reservation that is outside of their security boundaries. 

16.3 Business Exceptions 

If a user attempts to edit a reservation that is outside of their security boundaries, an error message of "User 
is not authorized to edit this reservation" should be displayed. 

16.4 System Exceptions 

None identified at this time. 
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17. Results Feedback Line Area 

17.1 Behavior 

This feedback area provides the user with the search result list count as well as list navigation. 
Search Result Count 

This area will display a count of the records currently being displayed in the result set area, as well as the 
total number of records returned in the result set area. The system will display the result set in blocks of 
20. If the result set is fewer than 20, all the matches will be displayed. For example, if a search is returned 
that has 17 matches, this area will display "Items 1 - 17 of 17 Found". If the user is navigating through the 
result set and moves to the next block of 20 records, this area should update which set of records the user is 
currently viewing. For example, if the user has returned a search with 110 records, the system will initially 
display "Items 1 - 20 of 1 10 Found". If the user navigates to the next block, the system should display 
"Items 21 -40 of 110 Found". 
List Navigation Area 

The user may select the block of records available as returned by the invoked search criteria. These blocks 
are identified by sequential numbers, along with a First (1 st block of records) and Last (last block of 
records). Also appearing will the Previous and Next. When negotiating through the result list the 
sequential numbers will change depending upon the block of records being viewed, other blocks of records 
can be accessed via the Previous and Next hyperlinks. The Previous and Next, and appropriate blocks, 
should be enabled or disabled according to the positioning of the list. For example, if the list were 
displaying the first set of several sets of records, the Previous function would be disabled. Similarly, if the 
list were displaying the last set of records the Next function would be disabled. t 
This area will display the total number of records found for each search. 

17.2 Validation 

None identified at this time. 

17.3 Business Exceptions 

None identified at this time. 

17.4 System Exceptions 

Buttons and navigation areas would be enabled and disabled appropriately for position of result list display. 

18. Button Line Area 

18.1 Behavior 

The Search image/button will invoke the search process, submitting the form to the server. 

The Reset image/button will clear all of the search criteria areas on the panel, but not reset the group or 
branch or remove the result set, if one is displayed. It will also not affect the results display area. 

The Print Current Page and Print All Records images/button are just placeholders. Their functionality and 
scope are outside of this use case and behavioral document. 

The New Reservation button will create a new reservation, changing the screen to that transaction. 

18.2 Validation 

None identified at this time. 

18.3 Business Exceptions 

If A Reservation Number is entered, all other search criteria are ignored, including group and branch. 

18.4 System Exceptions 

At least one-search criteria must be entered, other than group and branch. If not, an error message stating 
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"At lest one search criteria must be entered * 

19. Rules 

The Renter Name Last / First and Account Name search criteria have an implied wild card character placed 
directly after the entered text, all other search criteria fields on this screen are to be treated as exact matches 
with searching. 

There is a minimum of one-search criteria on which a search may be executed This does not include the 
Group and Branch selections. 

When there are not any matches to the input search criteria the user should be presented with a feedback 
message stating "Items 0 - 0 of 0 Found". 

If the search returns more reservations than can be displayed on the screen at one time, then the system 
needs to present to the user the range of records they are viewing out of the total number of records. 

All of the above search criteria, EXCEPT Reservation Number, will be limited to, or constrained by, the 
Group and Branch indicated or selected. 

20. Security 

The user must have the appropriate security level to access this screen. The user is allowed to view or print 
anything. It is when they attempt to edit a reservation that their security restrictions will be enforced. 
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Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the Insurance Details screen. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 

2. Drivers - Insurance Detail 


3 Insurance Detail - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 


DRIVERS 


James Atteberry 
Additional Drivers: 2 


REFERRAL 


Account Name 
Contact Name 


D AXES /RATES 


08/27/2001] ECAR 
Daily Rate; ASD 


Account Name 
Contact Name 


VEHICLE/SHOP 


1997 Dodge Avenger 
Shop Account Name 


Notes Taken; 1 
Changed; O8/27/2001 


Drivers - Insurance Detail 


I -Options- jH 


Atteberry, 
James 


Driver 


1 Smith, 

Cloud, 


[| Chris 

Kevin 



I 


ml 


Other Address 


Insurance Detail 


Cash Qualification 


rlnsurance Details* 
Carrier 


Agent 


Phone 


Insurance Company Contact 


Policy Number 


Expiration Date 


(MM/DD/YYYY) 


; Comprehensive Deductible 

Collision Deductible 

Liability? 

1 1 1 , 



Assigned Risk? 

Lienholder Policy? 







[ Tkt - 234S67 j Cbk - 363221 


Figure 1 - Insurance Detail 

3. Reservation Number 
3.1 Behavior 

This area shows the uniq ue reservatio n number t hat has been assi gned to the newlv created reservation. 
The reservation number is 6 alphanumeric charac ters long. If another re servation is open, its reservation 
number will displayed in this area as well. The user will have the ability to have to 3 reservatio ns ooen at a 
time. A hyperlink will be availa ble on the reservation numbers nf the reservations that are NOT currently 
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being displayed. For the reservation that is c urrently displayed, the reservation number will not have a 
hyperlink available. This is to allow the user to navig ate between the open reservations. 

3.2 Validation 

None identified at this time. 

3.3 Business E xceptions 

If the user tries to open a 4 th resevation. the system will displ ay a message s tating. "A maximum of 3 
reservations may be displayed." 

3.4 System Exceptions 

None identified at this time. 

4. Insurance Details 

4.1 Carrier 

4.1.1 Behavior 

This is an alphan umeric field. 

4.12 Validation 

No validation is necessary. See Rules regarding when the field is required. 

4.1.3 Business Exceptions * 
None have been identified at this time. 

4.1.4 System Exceptions 

None have been identified at this time. 

4.2 Agent 

4.2.1 Behavior 

This is an alphanumeric fields 

4.2.2 Validation 

No validation is necessary. The field is optional. 

4.2.3 Business Exceptions 

None have been identified at this time. 

4.2. 4 System Exceptions 

None have been identified at this time. 

4.3 Phone 

4.3.1 Behavior 

This is an al phanumeric field. It should comply with the standard phone number field formatting. 
r06/Q5/2Q01- To date, no European considerations have been noted (waiting on update to Use Case). 

Validation 

The field is optional. 
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4.4 

4.4.1 


4.4.2 

!i 

is J 

G 4.4.3 

ill 

02 

6 4.4.4 

W 

4.5 

Lis 

hi 

ill 

6 4.5.2 


4.5.3 


4.5.4 


4.6 


4.6.2 


See f/?e Soec/a/ P/?o/?e M/mber Req uirements at the end of the document for validation 
specifics.) 

Business Exceptions 

None have been identified at this time. 

System Exceptions 

None have been identified at this time. 

Insuranc e Company Contact 

Behavior 

This is an alphanumeric field. 

Validation 

No validation is necessary. See Rule s regarding when the field is req uired. 

Business Exceptions 

None have been identified at this time. 

System Exceptions $ 
None have been identified at this time. 

Policy Number 

Behavior 

This is an alp hanumeric field. 
Validation 

No validation is necessary. See Rules reg ar ding when th e field is required. 

Business Exceptions 

None have been identified at this time. 

System Exceptions 

None have been identified at this time. 

Expiration Date 

Behavior 

Only numeric values a nd delineatin g characters will be accepted into this area. 

Associated with this field is a calendar function that allows the user to sel ect a date from a calendar screen 
instead of entering a value. Clicking on the calendar icon will display the screen: once a date is selected 
from the screen the Ex piration Date field will be popula ted with the appropriate date. 

See Rules regarding when the field is required. 
Validation 

No validation is necessary. The field is optional. 
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4. 6. 3 Business Exceptions 

None have been identified at this time. 

4. 6. 4 System Exceptions 

None have been identified at this time. 

4.7 Comprehensive Deductible 

4.7.1 Behavior 



Validation 

No validation is necessary. See Rules regarding when the field is required. 

Business Exceptions 
None have been identified at this time. 

System Exceptions 
None have been identified at this time. 

Collision Deductible * 

Behavior 

This is a numeric field. 
Validation 

No validation is necessary. See Rules re garding when the field is required. 

Business Exceptions 
None have been identified at this time. 

System Exceptions 
None have been identified at this time. 

Liability? 

Behavior 

The response is either 'Yes' or but the re sponse is optional. There is no default value. 

4.9.2 Validation 

4.9.3 Business Exceptions 

None have been identified at this time. 

4. 9. 4 System Exceptions 

None have been identified at this time. 


4.7.2 
4.7.3 

hA 

U 4.7.4 

m 

?! 48 

W 4.8.1 

Li 

111 4.8.2 

m 

O 4.8.3 
4.8.4 


4.9 

4.9.1 
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4.10 Assigned Risk? 

4.10.1 Behavior 

The response is either 4 Yes ? or fc Nn\ but the response is optional. There is no default value. 

4.10.2 Validation 

No validation is necessary. The field is optional 

4.10.3 Business Exceptions 

None have been identified at this time. 

4.1 OA System Exceptions 

None have been identified at this time. 

4.11 Lienholder Policy? 

4.11.1 Behavior 

The response is eithe r ' Y es' o r ' N o 9 , but t he response is optional. There is no default value. 

4.11.2 Validation 

4.11.3 Business Exceptions 

None have been identified at this time. 

4.11.4 System Exceptions 

None have been identified at this time. 

5. Button Line Area 

5.1 Back Button 

The Back button will take the user to the main Driver screen for the currently select 


5.1.1 Validation 

None identified at this time. 

5.12 Business Exceptions 

None identified at this time. 

5.1.3 System Exceptions 

None identified at this time. 

5.2.1 Behavior 

The Complete button will initiate a save of the transaction. All validations will be performed, returning any 
errors to the user. If there are no errors, the transaction is saved, and the user is returned to the Reser 



5.2.2 Validation 

None identified at this time. 
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5. 2. 3 Business Exceptions 
None identified at this time, 

5. 2. 4 System Exceptions 
None identified at this time. 

6. Rules 

6.1 Required Fields 

These fields are only required if information is present in anv one of the following fields: C arrier. Policy 
Number. Expiration Date. Collision Deductible. Comprehensive Deductible. Liabilit y, Insuranc e Company 
Contact. If the system determines that anv of the listed fields are missing information, the system will 
present the user with a feedback message listing the inc omplete required fields and directing them to 
complete them. 

6.2 Saving 

Because none of the information on the screen is required, the user can leave the screen at anv time during 
the course of making or editing the reser vation or while opening, editing or closing the open ticket. The 
save is completed when the user saves the reservation or ticket. 

6.3 Tabbing * 

Tabbing bet ween fields sh ould be in th e order that thev are in this document 

7. Security 

The user must have the appropriate security level to access this screen. 


8. Special Ph one Number Requirements 

8.1 Overall Requirements 

The database has fields for the area code and phone number. 

Area cpde$ and phone numbers in North America are numeric only. Legacy phone numbers for North 
America are numeric only. 

Area codes and phone numbers in Europe may be character or numbers, Legacy phone number for 
Euro pe are both characters and numbers. 

8.2 Renter Specific 

Men navigating to a form w ith phone number fields, or when the page is submitte d, the phone number 
fields will be formatted according to the system locale. 

8.3 Insurance Phone Number 

The user will have a single field to enter the phone number. 

For North America, the user mav enter numbers only. All special characters will be ignored during 
formatting, anv characters will result in an error. A space is considered a special character. 
For Europe, t he user mav enter characters or numbers. At least one special character must be en tered. The 
first special cha racter will indicate the break between the area code an d the phone number. All other 
special characters are ignored. 
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8-4 Phone Number maskin g rules by r.nuntry- 

• The format for North America is HOO P XXX-XXXX 

• The format for Germany is: XXXXXXXX XX 

The area code mav vary in length, and is det ermined hv a special character entered hv the user to indicate 
where the break occurs. If the len gth of the phon e number (not including the area code) is odd, the first 
character is placed bv itself as shown above, the remaining charac ters are paired u p. If the length is even 
all characters are p aired up. 

• The format for Ireland and the UK is XX X.XXX.XXX XXX X 

The area code mav vary in length, and is dependent on the user en tering a sp eci al character between the 
area code and phone number. The characters following the area code should be grouped i n threes 
remaining characters grouped at the end ^ ~ 
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1. 


Screen Action Specification 

Introduction 

This document will describe the behavioral characteristics associated with the Insurance Details screen. 

The system must be able to distinguish, p resumabl y by the terminal ID. the proper screen language 
presentation as well as an v field form atting applicable to mat pa rticular locale. 

Screen Print 



drivers Drivers - Gash Qualification 


3ames Atte berry 
Additional Drivers: 2 


REFERRAL 


Account Name 
Contact Name 


DATES/RATES 


08/27/2001; ECAR 
Daily Rate; ASD 


BILL-TO 


Account Name 
Contact Name 


VEHICLE/SHOP 


1997 Dodge Avenger 
Shop Account Name 


Notes Taken: 1 
Changed: 


| Atte berry; 1 

Smith, 

Cloud, 

I James I 

Chris 

Kevin 



Driver 


Other Address 


Insurance Detail 


Cash Qualification 


pCash Qualification 1 — - 1 1 

How long at the current address: [0 J Years 

Months 

Ownership: 


Employment Verification - 
Employer 


Position 


Supervisor's Name 


Spoke To Whom 


How Long? 
(O M Years 
B Months 


r Rental Information 

Reason for Renting: O Car In Shop 

P Weekend 


Rented Previously: 
. .1 


f 


i 

it* 




Ftqurel - Cash Qualification Address & Employment V erification 
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5 CashQuall - Microsoft Internet Explorer provided fey JEn+crortse Senf-o-Car 



DRIVERS 


James Atteberry 
Additional Drivers? 2 


REFERRAL 


Account Name 
Contact Name 


DATES /RATES 


08/27/2001; ECAR 
Daily Rate; ASD 

Account Name 
Contact Name 

1997 Dodge Avenger 
Shop Account Name 


Notes Taken; 1 
Changedi 


Drivers - Cash Qualification 


Atteberry, 

James 


Driver 


| Smith, 

Cloud, 


f Chris 

Kevin 



Othe.r Address 


[ Insuran 


Insurance Detail 


r Rental Inform at'o n — - 

Reason for Renting: D Car In Shop 

LI Weekend 

D Vacation 

D Other: ) 


Rented Previously: 


[ 


If so, when? | 


Do you own a car ? 


[ 


-References (Three Different People}- 
RrstName Last Name 


Phone Number Relationship 


3[ 



Figure 2 - C ash Qualification Renter Information 
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IPs 

pT; 
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S' ' s 

hi 
3i 

hi 
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pen Tictet Cash Qial - Micwsoft Interarf Expfow provided by Eitfcrpris* Rcnf-a-Car 



Dates summary 1 
Dates summary 2 

Bill-To summary 1 
Bill-To summary 2 


VEHICLE/SHOP 


Vehicle/Shop 1 
Vehicle/Shop 2 


Notes summary 1 
Notes summary 2 


-References (Three Different People) 

First Name Last Name 

i- l id 

2. 


Phone Number Relationship 


3[ 


-Authorized By 

User Id Password 

CZ3 


Figure 3 - C ash Qualification 
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3. Top (see Figure 1) 

3.1 Years at curr ent address 

3.1.1 Behavior 

This is * dron down list of integers a nd zero. The dro p down should start at 0 and go through 9, followed 
bv u 10+ , \ 

3.1.2 Validation 

No validation is necessary. Th e field is optional. 

3.1.3 Business Exceptions 

None have been identified at this time. 

3. 1. 4 System Exceptions 

None have been identified at this time. 

3.2 Months at cu rrent address 

3.2.1 Behavior 

Thk a Hmp dnwn list of integers and gem Thp Hmp down should start at 0 andgo through 1 1, 

3.22 Validation 

No validation is necessary. The field is optional 

3. 2 3 Business Exceptions 

None have been identified at this time. 

3. 2 4 System Exceptions 

None have been identified at this time. 

3.3 Ownership 

3.3.1 Behavior 

Thi. k * Hrn p down list nf two values fawn & rentt pi n s * Matik. Since the selection is optional, it should 
default to blank. 

3.3.2 Validation 

No validation is necessary. The, field is optional 

3.3.3 Business Exceptions 

None have been identified at this time. 

3. 3. 4 System Exceptions 

None have been identified at this time. 
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4. Employment Verification (see Figure 1) 
4.1 Employer 

4.1.1 Behavior 

This is an alphanumeric field. 

4.1.2 Validation 

No validation i s necessary. The field is ooti 


4A1 


4.1.3 Business Exceptions 

None have been identified at this time. 

4.1.4 System Exceptions 

None have been identified at this time. 

4.2 Position 

4.2.1 Behavior 

This is an alph anumeric field. 

4.2.2 Validation 

No validation is necessary. The field is optional. 

4. 2. 3 Business Exceptions 

None have been identified at this time. 

4.2. 4 System Exceptions 

None have been identified at this time. 

4.3 Supervisor's Name 

4.3.1 Behavior 

This is an alphanumeric field. 

4.3.2 Validation 

No validation is necessary. The field is optional. 

4. 3. 3 Business Exceptions 

None have been identified at this time. 

4. 3. 4 System Exceptions 

None have been identified at this time. 

4.4 Spoke to Whom 



meric field. 
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4.4.2 Validation 
No validation is necessary. The field is optional 

4. 4. 3 Business Exceptions 
None have been identified at this time. 

4. 4. 4 System Exceptions 
None have been identified at this time. 

4.5 Years at Employer 

4.5.1 Behavior 

bv"10^\ 

4.5.2 Validation 

No validation is necessary. The field is optional 

4. 5. 3 Business Exceptions 

None have been identified at this time. 

4. 5. 4 System Exceptions 

None have been identified at this time. 

4.6 Months at Employer 

4.6.1 Behavior 

This is a drop down list of integers and zero. The dro p down should start at 0 and go through 1 1 . 


9, followed 


4.6.2 Validation 


The field is optional 


4. 6. 3 Business Exceptions 
None have been identified at this time. 

4. 6. 4 System Exceptions 
None have been identified at this time. 

5. Rental Information (see Figure 2) 

5.1 Reason for Renting 

5.1.1 Behavior 

This is a cho ice among four values: Car in Shoo. Wc 
optional it should default to nothing selected. 


and Other. Since the selection is 


5.1.2 Validation 

The selection and description 
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If Other is selected, then the field next to it is enabled to allow a description. The description is not 

5.1.3 Business Exceptions 

None have been identified at this time. 

5. 1.4 System Exceptions 

None have been identified at this time. 

5.2 Rented Previously 

5.2.1 Behavior 

This is a drop down of two values (ves & no) and a blank. Since the selection is optior 


5.2.2 Validation 
IMjelection and descriptor 

5. 2. 3 Business Exceptions 

None have been identified at this time. 

5.2.4 System Exceptions * 
None have been identified at this time. 

5.3 If so r when? 

5.3. 1 Behavior 

This is an alphanumeric field. If the answer to "Rented Previously" is Yes, then this field i s enabled to 
allow an answer. The answer is not required. 

5.3.2 Validation 

The selection and description are optional. 

5.3. 3 Business Exceptions 

None have been identified at this time. 

5. 3. 4 System Exceptions 

None have been identified at this time. 

5.4 Do you own a car? 

5.4.1 Behavior 

This is a drop down of two values fYes & No) and a blank. Since the selection is optional, it should default 
U 

5.4.2 Validation 

The selection is optional. 

5. 4. 3 Business Exceptions 

None have been identified at this time. 
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■J : 

H 

:i;:;r. 


1! .3 « 


5.4.4 System Exceptions 

None have been identified at this time. 

6. References (see Figure 2) 

This section is not a dynamic list bu t rather a set of 3 names and asso ciated information (b elow) which can 
be entered bv the user. 

6.1 First Name (column) 

6.1.1 


This is an al phanumeric field. 

6.12 Validation 

No validation i s necessary. The field is o ptional. 

6.1.3 Business Exceptions 

None have been identified at this time. 

6.14 System Exceptions 

None have been identified at this time. 

6.2 Last Name (column) 

6.2.1 Behavior 


U This is an alphanumeric field. 


111 6.2.2 Validatior 


rw 

11] No validatio n is necess ary. The field is optional. 

Q 

|,i 6.2.3 Business Exceptions 

None have been identified at this time. 

6. 2. 4 System Exceptions 

None have been identified at this time. 

6.3 Phone Number (column) 

Behavior 

This is an alphanumeric field. There are currently no validations to be perf ormed on this field. 
(06/05/2001- To date, no European considerations have been not ed (waiting on update to Use 
Case). 

6.3.1 Validation 

None have been identified at this time. 

6. 3. 2 Business Exceptions 

None have been identified at this time. 
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6. 3. 3 System Exceptions 

None have been identified at this time. 

6.4 Relationship (column) 

6.4.1 Behavior 

This is an alphanumeric field. 


6.4.2 


5 7. 

ill 

03 7A 

;*# 7 11 

H 

3 -.3 


ill 


Li 


No validation is necessary. The fiel d is optional. 


6. 4. 3 Business Exceptions 

None have been identified at this time. 

6. 4. 4 System Exceptions 
None have been identified at this time. 

Authorized By 


User ID 

Behavior 

This is an alphanumeric field and should conform to the standards for User ID. 


7.1.2 Validation 


Must be a valid employee, authorized to the Rental Application. 


7.1.3 Business Exceptions 

None have been identified at this time. 


7. 1. 4 System Exceptions 

None have been identified at this time. 

7.2 Password 

7.2.1 Behavior 

This is an alphanumeric field and should conform to the standards for Passwords. 

7.22 Validation 

Must be the employee's password. 

7. 2. 3 Business Exceptions 

None have been identified at this time. 

7.2.4 System Exceptions 

None have been identified at this time. 
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8. Button Line Area 

8.1 Back Button 

8.1.1 Behavior 

The Back button will take the user to the main Driver screen for the currently selected Driver. 

8.12 Validation 

None identified at this time. 

8. 1.3 Business Exceptions 
None identified at this time. 

8.1.4 System Exceptions 
None identified at this time. 

8.2 Complete button 

!!? 8.2.1 Behavior 

rj 

p| The Complete button will initiate a save of the transaction. All validations will be p erformed , returning any 

K errors to the user. If there are n o errors, the transaction is s aved, and the user is returned to the Reservation 

home page. 


ft 


□ 8.2.2 Validation 

N None identified at this time. 

8.2.3 Business Exceptions 

None identified at this time. 


a! 


fW 8.2.4 System Exceptions 

m 

m 


None identified at this time. 

9. Note for OPEN fvs. Reservation) 

Password and employee ID will be added at the bottom for authentication of the person authorizing the 
Cash Qualification. 

10. Rules 

10.1 Required Fields 

10.2 Tabbing 

Tabbing betwe en fields sh ould be in the following o rder: Current Emi 

Position: 

How long at cur rent job: year s 
Su pervisor's Name: 
Sooke to Whom: 
How long at cur rent iob: months 
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10.3 Saving 

Because none of the information on the screen is r equired, th e user can leave the screen at anv time. The 
save is completed when the user saves the reservation or ticket. 


11. Security 

The user must have the appropriate security level to access this screen. 
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Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the Driver screen. 


The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 


2. Driver Screen 


11 


il 


131 

s 
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Reservation: 411781 



REFERRAL 


RENTAL DATES 


Drivers 
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Drivers 


"Have you rented with us before?" 


Driver's License Detail 
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Cash Qualification 


j RENTERS VEHICLE 
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Primary Payment Method 

1 1 
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61 
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Figure 1 - Driver Screen 
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3. Reservation Number 


3.1 Behavior 

This area shows the unique reservation number that has been assigned to the newly created 
reservation. The reservation number is 6 alphanumeric characters long. If another reservation is 
open, its reservation number will be displayed in this area as well. The user will have the ability 
to have up to 3 reservations open at a time. A hyperlink will be available on the reservation 
numbers of the reservations that are NOT currently being displayed. For the reservation that is 
currently displayed, the reservation number will not have a hyperlink available. This is to allow 
the user to navigate between the open reservations. 

3.2 Validation 

None identified at this time. 

3.3 Business Exceptions 

If the user tries to open a 4 th reservation, the system will display a message stating "A maximum 
of 3 reservations may be displayed". 

3.4 System Exceptions 

None identified at this time. 


4. Driver Navigation Area 

4.1 Behavior 

This area gives the user the ability to move to any screen within the Driver area. Each screen 
within the Driver area is connected by a hyperlink. The screens that have been defined are: 
Driver, Driver's License Detail, Insurance Detail, and Cash Qualification. A hyperlink will NOT be 
available for the screen that is currently displayed. 

4.2 Validation 

None identified at this time, 

4.3 Business Exceptions 

None identified at this time. 

4.4 System Exceptions 

None identified at this time. 

5. Driver's First and Last Name 

5.1 Behavior 

This area is divided into two fields. 

• Last Name 

• First Name. 

Both fields are free form text fields and may contain alphanumeric values. 

5.2 Validation 

None identified at this time. 

5.3 Business Exceptions 

If the user attempts to exit the screen or complete the reservation, the last name field must have 
values entered. If there are not values in the last name field, the system will display a message 
"Last Name is required for a Reservation". 
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5.4 System Exceptions 

None identified at this time. 

6. Address and Other Address Area 

6.1 Behavior 

This area is broken into two free form text areas. The user has the ability to enter strings of 
alphanumeric values. The first area is called "Address" and the other area is called "Other 
Address". 

6.2 Validation 

None identified at this time. 

6.3 Business Exceptions 

None identified at this time. 

6.4 System Exceptions 

None identified at this time. 

7. City, State, Zip Code and Country, and City Other, State Other, Zip Code 
Other and Country Other Areas 

7.1 Behavior 

These behaviors are detailed out in the Geo-Framework Search Screen Sjpec 

7.2 Validation 

None identified at this time. 

7.3 Business Exceptions 

None identified at this time. 

7.4 System Exceptions 

None identified at this time. 

8. Primary Payment Method Area 

8.1 Behavior 

This area is a drop down box that allows the user to select a Primary Payment Method. The valid 
values that are available within the drop-down list are: Cash, Credit Card, Debit Card, and Check. 
Upon initial entry to the screen, the value in the drop down should be defaulted to "Credit Card". 
- The user can change the value by selecting another value from the drop down list. There is no 
blank or "other" option available. 

8.2 Validation 

None identified at this time. 

8.3 Business Exceptions 

None identified at this time. 

8.4 System Exceptions 

None identified at this time. 
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9. Home Phone Area 

9.1 Behavior 

The Home Phone area is a free form text area that will allow the user to input alphanumeric 
values. 

9.2 Validation 

None identified at this time. 

9.3 Business Exceptions 

None identified at this time. 

9.4 System Exceptions 

None identified at this time. 

1 0. Work Phone Area 

10.1 Behavior 

P The Work Phone area is a free form text area that will allow the user to input alphanumeric 

III values. 

10.2 Validation 

None identified at this time. * 

yJ 10.3 Business Exceptions 

v ' None identified at this time. 

I* 

111 10.4 System Exceptions 

ij None identified at this time. 


^4 


03 

ijtaw. 


1 1 . Phone Extension Area 

11.1 Behavior 

The Phone Extension area is a free form text area that will allow the user to input alphanumeric 
values. This area would not be enabled until there was a value entered into the Work Phone area. 

11.2 Validation 

There must be a value in the Work Phone area before this area is enabled. 

1 1 .3 Business Exceptions 

None identified at this time. 

1 1 .4 System Exceptions 

None identified at this time. 

12. Employer Area 

12.1 Behavior 

The Employer area is a free form text area that will allow the user to input alphanumeric values. 

12.2 Validation 

None identified at this time. 

12.3 Business Exceptions 

None identified at this time. 
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12.4 System Exceptions 

None identified at this time. 

13. Other Phone Area 

13.1 Behavior 

The Other Phone area is a free form text area that will allow the user to input alphanumeric 
values. 

13.2 Validation 

None identified at this time. 

13.3 Business Exceptions 

None identified at this time. 

13.4 System Exceptions 

None identified at this time. 

14. Phone Type Area 

14.1 Behavior 

This area will be a drop down area that upon default will be a blank. When the user clicks the 
drop down area, the system will display the domain of Phone Types available. 

14.2 Validation 

If there is a value entered in the Other Phone area, then a type other than blank must be selected. 

14.3 Business Exceptions 

If values exist within the Other Phone area, the system will also verify that a value, other than 
blank, has been selected from the drop down area Phone Type. If one has not been selected, 
the system displays a message "Phone Type must be selected". 

14.4 System Exceptions 

None identified at this time. 

15. Button Line Area 

15.1 Behavior 

The Search image/button will invoke the search process, submitting die form to the server. 

The Add Driver image/button will invoke the additional driver panel, submitting the form to the server. 

15.2 Validation 

None identified at this time. 

15.3 Business Exceptions 

None identified at this time. 

15.4 System Exceptions 

None identified at this time. 

16. Rules 

None identified at this time. 
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17. Security 

The user must have the appropriate security level to access this screen. The user is allowed to view or print 
anything. It is when they attempt to edit a reservation that their security restrictions will be enforced. 
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"Ticket Opened" 

"Ticket Opened" 

Any text within the preference field 

Text in the field "Vehicle Notes" 

Reservation # "XXXXXX" was (un) 
matched to Ticket # "XXXXXX". 

"Reservation Created" 

"Renter Has Been Contacted" AND any 
text entered in the ARMS Notes field 

"Renter Has Been Contacted" AND any 
text entered in the ARMS Notes field 

Pick-up Date "XX/XX/XXXX" was 
changed to "XX/XX/XXXX" 

Pick-up Time "XX: XX" was changed to 
"XX: XX" 

Pick-up Method "XX" was changed to 
"XX". 

Pick-up Location "XXXX" was changed 
to "XXXXX" 

Return Date "XX/XX/XXXX" was 
changed to "XX/XX/XXXX" 

Return Time "XX: XX" was changed to 
"XX: XX" 

Return Method "XX" was changed to 
"XX". 

Rate Source "XXXXX" was changed to 
"XXXXX" 

Rental Type "XXXX" was changed to 
"XXXX" 

Car Class "XXXX" was changed to 

'IS''' ' 

A Reservation becomes an open ticket after the 
reservation has already been created. 

A new ticket it is created 

When a ticket is opened, the information in the 
preference field will be generated as a note 

When a ticket is opened, the text in the field, 
vehicle notes, will be generated as a note 

A reservation is matched or unmatched to a Ticket 

A reservation is created 

The user marks the ARMS Status Dialog Box as 
"Renter Has Been Contacted" 

The user marks the ARMS Status Dialog Box as 
"Renter Has Not Been Contacted" 

The Reservation Pick-up date is changed 

The Reservation Pick-up time is changed 

The Reservation pick-up method is changed 

The Reservation pick-up location is changed 

The Reservation Return date is changed 

The Reservation Return time is changed 

The Reservation return method is changed 

The Rate Source and/or Account Number are 
chaneed 

The Rental Type is changed 

The Car Class is changed 
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Screen Action Specification 

1. Introduction 

This document describes the behavioral characteristics associated with the Transfer Reservation screen, and its 
related screens. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language presentation as 
well as any field formatting applicable to that particular locale. 


2. Screen Shots 


-3 E3846G 0101 Enterprise* ECARS Application - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 


drivers 1 Transfer Reservation 


ii ii 


REFERRAL 


DATES /RATES 


11/08/2001 02:30 PM 


filLL-TQ 


VEHICLE/SHOP 


Notes Taken : 1 


-Pickup Information - 
Pickup Date: Thursday November 08, 2001 
Pickup Time: 02:30 PM 

Group: 

|01 - ST LOUIS "~" 



Branch: 


ELADUE RENTAL 0101 


** Changing the Pickup Branch may change the 
rental rate * * 


Address 

8844 LADUE ROAD LADUE, 
MO 63124-2087 

Hours Of Operation 

Monday 

Tuesday 

Wednesday 

Thursday 

Friday 

Saturday 

Sunday 


Phone Number 
(314) 863-6886 

7:30 AM -6:00 PM 
7:30 AM -6:00 PM 
7:30 AM - 6:00 PM 
7:30 AM - 6:00 PM 
7:30 AM - 6:00 PM 
8:00 AM - 3:00 PM 
Closed 


Return Information 


Return Date: Wednesday November 28, 2001 

Return Time: 03:45 PM 

Group: 

|01 - ST LOU IS 3 

Branch: 

lO FALLON ILLINOIS 0129 


Address 

1603 WEST HIGHWAY 50 
O'FAULON, It 62269-1622 

Hours Of Operation 

Monday 

Tuesday 

Wednesday 

Thursday 

Friday 

Saturday 

Sunday 


Phone Number 
(618) 632-7200 

7:30 AM -6:00 PM 
7:30 AM - 6:00 PM 
7:30 AM -6:00 PM 
7:30 AM -6:00 PM 
7:30 AM -6:00 PM 
8:00 AM - 12:00 AM 
Closed 


Res -13775H 


Res -975254 


ml 

i * J 

: 


,'i> 


v ,3 

tt t , 
*f '< 


Figure 1: Transfer Reservation (Reservation Pilot Version) 
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IDriver summary 1 
IDriver summary 2 


REFERRAL 


Referral sum 1 
Referral sum 2 


DATES/RATES 


Dates summary 1 
Dates summary 2 

Bill-To summary 1 
Bill-To summary 2 


VEHICLE/SHOP 


Vehicle/Shop 1 
Vehicle/Shop 2 

Notes summary 1 
Notes summary 2 


- Pickup - 
Gp/Br; 

Date: 


0101 
Time: 


MM/DD/YYYY 
Method: 


HH:MM A 
Location: 


-Return - 
Gp/Br: 

Date: 


0101 
Time: 


Ji 


MM/DD/YYYY 
Method: 


HH:MM A 
Location: 


rRate Sources- 
Account Name 


Account Number 


Rental Type 


j-Select- 


Rate Plan 


Car Class 


| -Select- 



r Rates- 


15.9$ 


150! 


59.99t 



5.99jl 1 0.1 1 .13 



3- 

3.1 


Figure 2: Dates and Rates (with Pick-Up and Return Group/Branch Information) 

Field Descriptions 

Transfer Reservation Main Paae 


3.1.1 Pick-Up Date 
3.1.1.1 Behavior 

This field is a read-only text field that displays the date of the res ervation pick-up. The format of the date is such 
that the user is aware of th e dav of the week that the pick -up is to occur, for example. Tuesday. August 28, 2Q01 . 
:ofthedateis specific to 


If a pick-up 

3.1.1.2 Validation 
None identified at this time. 

3.1.13 Business Exceptions 
None identified at this time. 

3.1.1 .4 System Exceptions 
None identified at this time. 


the reservation, this fiel 
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3.12 Pick-Up Time 
3.1.2.1 Behavior 

This field is a read-only text field that displays the reservation pick-iro time. The format of the time is specific to the 
location that t he branch is i n. For 12-hour locales, it is H H:MM A and for 24-hour locales, it is HH:MM. 


If a pick-up time is not entered in the reserv ation, this field will be blank. 

3.1.2.2 Validation 
None identified at this time. 

3.1.2.3 Business Exceptions 
None identified at this time. 

3.1.2.4 System Exceptions 
|»£i None identified at this time. 

O 

Q 3.1.3 Return Date 

§1 3.1.3.1 Behavior 

0 This field is a read-only text field that displays the return date. The date is displayed in a format so that the user is 
SI aware of the dav of the wee k that the pic k-up is to occur, for example. Tuesday. August 2S1 2001. The actual format 
yj of the date is specific to t h e location of the branch. 

f*A If a return da te is not entered in the reservation, this field will be blank . 

1 U 
34 9 

!Jf 3.1.3.2 Validation 

ni 

None identified at this time. 

y< 3.1.3.3 Business Exceptions 
None identified at this time. 

3.13.4 System Exceptions 
None identified at this time. 

3.1.4 Return Time 
3.1.4.1 Behavior 

This field is a read -only text field that displays the reserv ation return time. The for mat of the time is specific to the 
location that the br anch is in. For 12-hour lo cales, it is HH:MM A an d for 24-hour locales, it is HH:MM. 

Tf a return time is not entered in the reservation, this field will be blank. 


3.14.2 Validation 
None identified at this time. 

3.14.3 Business Exceptions 
None identified at this time. 

3.1.4.4 System Exceptions 
None identified at this time. 
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3.15 Pick-Uo Group 

3.1.5.1 Behavior 

This field area is a drop down box, limited to those groups that exist at the point in time that the screen is opened. 
The user will be able to type a character, alpha or numeric, into the are a and have the drop down list position to the 
character. For example, if the user types an *H' the dro p down list would position to the first string beginning with 
>H\ The default item will be the group associated to the terminal locale or the currently saved pick-up group. 

3.1.5.2 Validation 

The items appearing in the list are static: t he user cannot add items to the list dynamically. For the purposes of Pilot 
Reservation, t he group drop-down box will he disabled. For full release, the field will be enabled based on security 
roles. When the Transfer Reservation screen is initially open ed on a ne w reservation , the pick-up group field will 
default to t he terminal's grou p. When the Transfer Reservati on screen is initially opened for a previously saved 
reservation, the pick-up group field will default to the location that was saved with the reservation. 

3.1.5.3 Business Exceptions 
None identified at this time. 

3.1.5.4 System Exceptions 
None identified at this time. 

3.16 Pick-Uo Branch 

3.1.6.1 Behavior * 
This field area is a drop d own box, li mited to those rental branches that exist at the point in time that the screen is 
opened in the ^roup that i s selected in t he Pick-Up Group field. The user will he able to type a character, alpha or 
numeric, int o the area and have the drop down list position to the character. For example, if the user types an ft H' 
the dro p dow n list would position to the first string beginning with *H\ The default item will be the branch 
associated to the terminal locale or the currently saved pick-up branch. 


3.1.6.2 Validation 

The items appearing in the list are static: the user c annot add items to the list dynamically. When the Transfer 
Reservation screen is initially opened on anew reservation, the p ick-up branch field will default to the terminal's 

• Reservation sc reen is initially opened for a previously saved re$ervation, the pick-up 


branch field will default to the location that was saved with t he reservation. 
3.1.6.3 Business Exceptions 


None identified at this time. 

3.1.6.4 System Exceptions 
None identified at this time. 


3.17 Return Group 
3.1.7.1 Behavior 

This field area is a drop down box, limited to those groups that exist at the point in time that the screen is opened. 
The user will he able to type a character, al pha or nu meric, into the area and h ave the drop down list position to the 
character. For example, if the user types an 'W the dron down list would position to the first string beginning with 
'FT. The default item will be the group associated to the terminal locale or the currently saved return group. 
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3.1.7.2 Validation 

The items ap pearing in the list are static: the user cannot add items to the list dynamically. For the pu rposes of Pilot 
Reservation, the group drop-down box will be disabled. For full release, the field will be enabled based on security 
roles. When the Transfer Reservation screen is initially opened on a new reservation, the pick -up group field will 
default to the terminal's group. When the Transfer Reservation screen is initially opened for a previously saved 
reservation, the return group field will default to the location that was saved with the reservation. 

3.1.7.3 Business Exceptions 
None identified at this time. 

3.1.7.4 System Exceptions 
None identified at this time. 

3.18 Return Branch 
3.1.8.1 Behavior 

This field area is a dro p down box, limited to those rental b ranches that exist at the point in time that the screen is 
opened in the group tha t is selected in the Return Gr oup field. The user will be able to type a character, alpha or 
numeric, into the ar ea and have t he dro p down list position to the character. For e xample, if the user types an 'IT 
the dro p down list would po sition to the first string beginning with 'H'. The default item will be the branch 
55 associated to the terminal locale or the currently saved pick-w branch. 


3-.S- 


3 a 
2 


U 

a :; 

W 


When the user selects a new Pick-Up Branch, the Return Branch field automatically changes to the same branch. 


I** 3.1.8.2 Validation 

vA The items appearing in the list are static: the user cannot add items to the list dynamically- When the Transfer 

ill Reservation screen is in itially op ened on a new r eservation^ th e pick-up b ranch field will default to the terminal's 

!P group. When the Transfe r Reservation screen is initi ally o pened f or a previously saved reservation, the return 

Q branch field will default to the location that was saved with the reservation. 


3.1.8.3 Business Exceptions 

None identified at this time. 

3.1.8.4 System Exceptions 
None identified at this time. 

3.19 Rental Rates Note 

3.19.1 Behavior 

This field is a read-only label that displa ys an alert to the user. It always appears on the screen to notify the user that 
chan ging the pick-up location mav cha nge the quoted rental rates. 

3.19.2 Validation 
None identified at this time. 

3.19.3 Business Exceptions 
None identified at this time. 

3.1.9.4 System Exceptions 
None identified at this time. 
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3.1.10 Pick-Up Branch Availability Note 

3.1.10.1 Behavior 

This field is a read-only label that notifies the user if the selec ted pick-up branch is not open. It is displayed above 
the selected branch address, if applicable. 

Tf the user selects a pick-up bran ch that is not open for the entered pick-up time then , a note will appear in red text 
that states. "The pick-up location is closed during selected hours". 

If the pick-up date and time are not entered, then the message will not appear, if the pic k-up date is entered without 
the time, the message will only appear if the branch is closed for the ent ire selected dav. 

3.1.10.2 Validation 
None identified at this time. 

3.1.10.3 Business Exceptions 
None identified at this time. 

y 3.1.1 0.4 System Exceptions 
P None identified at this time. 

0 3.1.11 Return Branch Availability Note 

n 

u\ 3.1.11.1 Behavior 

This field is a read-only label that notifie s the user if the selected return branch is not onen. It is displayed above the 
\A selected bra nch address, if applicable. 

A If the user selects a return branch that i s not open for the entered r eturn time then, a note will appear in red text that 

m states "The r eturn location is closed during selected hours". 
i„ ., _____ 

lH 

J r f Tf the return date and time are not entere d, then the message will not ap pear. If the return date is entered without the 
^ time, the mes sage will only ap pear if the branch is closed for the entire selected day. 

3.1.11.2 Validation 
None identified at this time. 

3.1.11.3 Business Exceptions 
None identified at this time. 

3. 1 . 1 1 .4 System Exceptions 
None identified at this time. 

3.1.12 Pick-Up Branch Address 

3.1.12.1 Behavior 

The Pick-U p Branch ad dress is a rea d-only label that is based upo n the Pick-Up Group/Branch combination that i$ 
elected. It is not v isible when the screen is f irst opened. When the user selects a new Pick-Up Branch, this field 
will automatically u pdate with the selected Pick -Up Branch's address. 

3.1.12.2 Validation 
None identified at this time. 


Confidential 


©Enterprise Rent-A-Car 2000 


Page 9 


Reservations 

Version: 1.4 

Screen Action Specification 

Date: 12/21/01 

Transfer Reservation 


3.1.12.3 Business Exceptions 
None identified at this time. 

3.1.12.4 System Exceptions 
None identified at this time. 

3.1.13 Pick-Up Branch Phone Number 

3.1.13.1 Behavior 

The Pick-Up Branch phone number is a read-only label that is based upon the Pick-Up Group/Branch combination 
that is selected. Tt is not visible when the screen is first opened. When the user selects a new Pick-Up Branch, this 
field will automatically update with the selected Pick-Up Branc h's phone number. 

3.1.13.2 Validation 
None identified at this time. 

3.1.13.3 Business Exceptions 
None identified at this time. 

3.1.13.4 System Exceptions 
None identified at this time. 

3.1.14 Pick-Up Branch Hours of Operation 
3.114.1 Behavior 

The Pick-Up Branch ho urs of operat ion field is a read-only label that is based upon t he Pick-Up G roup/Branch 
combination that is selected. It is not visible whe n the screen is first opene d. When the u ser selects a new Pick-Up 
Branch, this field will automatically update with the selected Pick-Up Branch's hours of operation. The hours of 
operation are displayed in the time lo cal to the sele cted branch. 

3.1.14.2 Validation 
None identified at this time. 

3.1.14.3 Business Exceptions 
None identified at this time. 

3.1.14.4 System Exceptions 
None identified at this time. 

3.115 Return Branch Address 

3.1.15.1 Behavior 

The Return Branch address is a read-only label that is based upon the Return Group/Branch combination that is 
selected. It is not visible when the screen is first opened. When the user se lects a new Return Branch or the Return 
Branch is cha n ged, this field will automat ically update with the selected Return Branch's address. 

3.1.15.2 Validation 
None identified at this time. 

3.1.15.3 Business Exceptions 
None identified at this time. 

3.1.15.4 System Exceptions 
None identified at this time. 
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3.1.16 Return Branch Phone Number 

3.1.16.1 Behavior 

The Retur n Branch phone number is a read-only label that is based u pon the Return G roup/Branch combination that 
is selected. It is not visible when the screen is first opened. When the user selects a new Return Branch or the 

3.1.16.2 Validation 
None identified at this time. 

3.1.16.3 Business Exceptions 
None identified at this time. 

3.1.16.4 System Exceptions 
None identified at this time. 

3.1.17 Return Branch Hours of Operation 
3.1.17.1 Behavior 

The Return B ranch hours of operation field is a read-o nly label that is based upon the Return Group/Branch 
combination that is selecte d. When the u ser selects a n ew Return Bran ch or the Return Branch is changed, this field 
will automatically u pdate w ith the selected Return Branch's hours of operation. The hours of operation are 
displayed in the time local to the selected branch. ^ 

3.117.2 Validation 
None identified at this time. 

3.1.17.3 Business Exceptions 
None identified at this time. 

3.1.17.4 System Exceptions 
None identified at this time. 

3.1.18 OK Button 

3.1.18.1 Behavior 

When the us er presses the 'OK' button, the system stores the data o n the screen, creates a system generated note and 
returns the use r to the main scr een of the navigation area that the user was in before navigating to Transfer 
Reservation Screen. 

3.1.18.2 Validation 
None identified at this time. 

3.1.18.3 Business Exceptions 
None identified at this time. 

3.1.18.4 System Exceptions 
None identified at this time. 


3.1.19 Cancel Button 

3,1.19.1 Behavior 

When the user clicks the '< 
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of the navigation area that the user w as in befor e navigating to the Transfer Reservation Screen.. 

3.1.19.2 Validation 
None identified at this time. 

3.1.19.3 Business Exceptions 
None identified at this time. 

3.1.19.4 System Exceptions 
None identified at this time. 

3.2 Dates and R ates Screen 

3.2.1 Pick-Up Group/Branch 

3.2.1.1 Behavior 

This is a read-only text field that displays the current pick-tip group/branch numbers. For a new reservation^ it will 
dis play the group/branch information for the terminal location. For an ex isting reservation, it will display the 
group/branch information that is stored with the reservation. After the user saves information on the Transfer 
Reservation page and closes the Transfer Reservation screen, this field will update with the new information. 

3.2.1.2 Validation 
None identified at this time. 

3.2.1.3 Business Exceptions 
None identified at this time. 

3.2.1.4 System Exceptions 
None identified at this time. 

3.22 Return Group/Branch 

3.2.2.1 Behavior 

This is a read-only text field that displays the current return grou p/branch numbers. For a new reservation, it will 
display the grou p/branch information for the terminal location. For an existing reservation, it will display the 
grou p/branch information that is stored with the reservation. Aft er the user saves information on the Transfer 

3.2.2.2 Validation 
None identified at this time. 

3.2.2.3 Business Exceptions 
None identified at this time. 

3.2.2.4 System Exceptions 
None identified at this time. 

4. Rules 

• A System Generated Note is generated every time a location is changed and the reservation is 
com pleted The system gene rated note is not saved to the reservation until the reservation ha$ been 
completed. 

• Transfer Reservation data is only saved to the rese 



= „ __j_the_option to transfer anv reservation in his/her group. 

The option t o transfer a reservation is found in the 'Op tions' drop down list from within a reservation. 
I not be available fc 
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• When a pick-up/return location is changed to a location in a different time zone, the re servation time 
changes so that it is the same in the new time zone. The database value fGMT) will be changed, but 
the value displayed to the user will be the same. Example: A person has a reservation at 4:00 PM 
(CST) in St. Louis and it is transferred to New York, the reservation will now be at 4:00 PM fEST). 

• When the pick-up branch is changed and the reservation is com pleted, the reservation will print at the 
new pick-up location. 

• The Transfer Reservation Screen is a full screen window. It will behave like other full screen$ in the 
application. 

• When the user navigates awav from the window via the left hand navig ation bar, the system will not 
store any changes that the user made on the Transfer Reservation screen. 

5. Security 

• The security for Transfer Reservation is base d u pon the Reservation security model. If the user has 
permissions to edit a reservation, he/she will be able to transfer it. In gener al, all users in a group can 
modify all res ervations for that group. 

6. Questions 

• If a user transfers a reservation to another time zone, what will happen to the pick-up/return time? For 
example, if a person has a reservation at 4:00 PM in St. Louis and it is transferred to New York, what 
time will the reservation be for (4:00 or 5:00)? The pick-up/return time will be the same. 

• Should everyone in a given branch have permissions to change the location for every other branch in 
that group? Yes 
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Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the Insurance Details screen. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 

2. Screen Print 


DRIVERS 


James Atteberry 
Additional Drivers: 2 


REFERRAL 


Account Name 
Contact Name 


DATES/RATES 


08/27/2001; ECAR 
Daily Rate; ASD 


BILL-TO 


Account Name 
Contact Name 


VEHICLE/SHOP 


1997 Dodge Avenger 
Shop Account Name 


Notes Taken: 1 
Changed: 08/27/2001 


Drivers - Insurance Detail 


Atteberry, 1 

Smith, 

Cloud, 

James § 

Chris 

Kevin 


Driver 


Other Address 


Insurance Detail 


[-Insurance Details - 
Carrier 


Agent 


Insurance Company Contact 


Policy Number 


r 


Comprehensive Deductible 


Collision Deductible 


Assigned Risk? 


Lienholder Policy? 



[- Options- Hi 


Cash Qualification 



Phone 


Expiration Date 


(MM/DD/YYYY) 


Liability? 


Res - 411781 


Tkt - 234567] Cbk- 36322 1] 


Figure 1 - Insurance Detail 

July 2001 
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Figure 2 - Date selection 
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3. Insurance Details 

3.1 Carrier 

3. 1. 1 Behavior 

This is an alphanumeric field . 

3. 1.2 Validation 

No validation is necessary. See Rules regarding when the field is required. 

3. 1. 3 Business Exceptions 

None have been identified at this time. 

3. 1. 4 System Exceptions 

None have been identified at this time. 

3.2 Agent 

3.2.1 Behavior 

This is an alp h anumeric field, 

3.2.2 Validation 

No validation is necessary. The field is optional. 

3.2.3 Business Exceptions $ 
None have been identified at this time. 

3.2.4 System Exceptions 

None have been identified at this time. 

3.3 Phone 

3.3.1 Behavior 

This is an alphanumeric field. Tt should co mply with the standard phone number fi eld formatting. 
(06/05/200 1- To date, no European co nsiderations have been noted f waiting on update to Use Case! 

3.3.2 Validation 

The field is optional 

It should be edited to comply with the locale's format (i.e. in the United States, the length is 10 digits and 
include delimiters after the 3 rd and 6 th charac ters. If no del imiters are used, but 1 0 digits are entered, that is 


3. 3. 3 Business Exceptions 

None have been identified at this time. 

3. 3. 4 System Exceptions 

None have been identified at this time. 

3.4 Insurance Company Contact 

3.4. 1 Behavior 

This is an alphanumeric field. 

3.4.2 Validation 

No validation is necessary. See Rules regarding when the field is required. 
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3. 4. 3 Business Exceptions 

None have been identified at this time. 

3. 4. 4 System Exceptions 

None have been identified at this time. 

3.5 Policy Number 

3.5.1 Behavior 

This is an alphanumeric field. 

3.5.2 Validation 

No validation is necessary. See Rules regarding when the field is required. 

3. 5. 3 Business Exceptions 

None have been identified at this time. 

3. 5.4 System Exceptions 

None have been identified at this time. 

3.6 Expiration Date 

3.6.1 Behavior 

Only numeric values and delineating characters w ill be accepted into this area. 

Associated with this field is a calend ar functio n that allows the user to select a date from a calendar screen 
instead of entering a valu e. Clicking on the calendar icon will dis play the scree n: once a da te is selected 
from the screen the Expiration Date field will be populated with the appropriate date. 

See Rules regarding w hen the field is required. 

3.6.2 Validation 

The date should be the current date o r a date in the future. 

3. 6. 3 Business Exceptions 

None have been identified at this time. 

3. 6.4 System Exceptions 

None have been identified at this time. 

3.7 Comprehensive Deductible 

3. 7. 1 Behavior 

This is a numeric field. 

3.7.2 Validation 

No validation is necessary. See Rules regarding when the field is required. 

3. 7. 3 Business Exceptions 

None have been identified at this time. 

3. 7 4 System Exceptions 

None have been identified at this time. 

3.8 Collision Deductible 

3.8.1 Behavior 
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3.8.2 Validation 

No validation is necessary. See Rules regarding when the field is required. 

3. 8. 3 Business Exceptions 

None have been identified at this time. 

3. 8. 4 System Exceptions 

None have been identified at this time. 

3.9 Liability? 

3.9.1 Behavior 

The response is either ' Yes* or 'No', but the response is opti onal. There is no default value. 

3.9.2 Validation 

No validation is necessary. See Rules regarding when the field is required 

3. 9.3 Business Exceptions 

None have been identified at this time. 

3.9.4 System Exceptions 

None have been identified at this time. 

3.10 Assigned Risk? ^ 

3.10.1 Behavior 

The response is either 4 Yes' or 'No', but the response is optional There is no default value. 

3.10.2 Validation 

No validation is necessary. The field is optional. 

3.10.3 Business Exceptions 

None have been identified at this time. 

3.10.4 System Exceptions 

None have been identified at this time. 

3.11 Lienholder Policy? 

3.11.1 Behavior 

The response i s either ' Yes* or 'No*, but the response is optional. There is no default value. 

3.11.2 Validation 

No validation is necessary. The field is optional. 

3:11.3 Business Exceptions 

None have been identified at this time. 

3.11.4 System Exceptions 

None have been identified at this time. 

4. Button Line Area 
4.1 Back button 

4.1.1 Behavior 

The Back button will take the user to the main Driver screen for the currently selected driver. 
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4.12 Validation 

No validation is necessary. 

4.1.3 Business Exceptions 

None have been identified at this time. 

4. 1.4 System Exceptions 

None have been identified at this time. 

4.2 Complete button 

4.2.1 Behavior 

The Complete button will initiate a save of the transaction. All validations will be performed, returning any 
errors to the user. If there are no errors, the transaction is saved, and the user is returned to the Reservation 
home page. 

422 Validation 

No validation is necessary. 

4. 2. 3 Business Exceptions 

None have been identified at this time. 

42.4 System Exceptions 

None have been identified at this time. $ 

5. Rules 

5.1 Required Fields 

These fields are only required if in formation is present in any one of the following fields: Carrier. Policy 
Number. Expiration Date. Collision Deductible. Comprehensive Deductible. Liability. Insurance Company 
Contact, If the system determines that anv of the listed fields are missing information, the sy stem will 
present the user with a feedback message listing the incomplete required fields and directing them to 
complete them. 

5.2 Saving 

Because none of the information o n the scre en is required, the user can leave the screen at anv time during 
the course of making or editing the reservation or while opening, editing or closing the open ticket Unless 
any of the field s in SUPL 76 are present. The save is completed when the user saves the reservation or 
ticket. 

5.3 Tabbing 

Tabbing between fields should be in the order that they are in this document. 

6. Security 

The user must have the appropriate security level to access this screen. 
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Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the Notes screen. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 

2. Screen Print 


Notes - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 


| Rie i4^ : ^2;f^??l:?^|||^; 


Reservatibn;f4&- ! 


drivers I Motes 


iDriver summary 1 
Driver summary 2 Type: 


|-QptiQns~^'|jgj[ 


REFERRAL 


Referral sum 1 
Referral sum 2 


DATES/RATES 


Dates summary 1 
Dates summary 2 


BILL-TO 


Bill-To summary 1 
Bill-To summary 2 


VEHICLE/SHOP 


Vehicle/Shop 1 
Vehicle/Shop 2 


NOTES 


Notes summary 1 
Notes summary 2 


ALL 


Status: 
H |ALL_ 


07/03/2001 Car is at Joe's Gar^ ~ CLOSE CALL&ACK ECARS 2.0 

3522PM USER 


07/02/2001 Does not like red cars, This shows the first two lines of 
2;22PM _the notes section.^ (3 45 cfwU 


OPEN SYSTEM SYSTEM SENT 


07/01/2001 Reservation Created 
ls22PM 


RESERVATION SYSTEM SYSTEM SENT 


SI Tkt - 234567 Cbk - 363221 


Notes screen 


Figure 1 - Notes 
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,3 ^_ — — . ■ 


1 

Add Note ■ 


;• Notes \ 





|' 
i 

1^ ■ 


j; 

is 

j; 

¥'! s; 


j; 
f 

ii 

I" 

j] 

^ li 
i: 

i 


I' 
s 

1 

B ifllll ! 


I 


Add Note* screen 


Figure 2 - Add Note 
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View Note 


Datei 7/02/2001 2s 22PM 

Status: Open 

Type; System 

Created Byi System 

Arms Msg; Sent 

Note; 


Does not like red cars. This shows the first two lines of the 
notes section. (2 8 45 char) 

The text area shown here is big enough to show 
the entire database field without scrolling. 


ft i 


View 


Note screen 
Figure 3 -View Note 
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3 Notes Lis* - Miciosoft Internet Explorer provided by Enterprise Rent-a-Car 


Notes List 


Reservation: 411781 
Renter; Joe Smith 
Date: 07/09/2001 


Date/Time 

Note 

Status 

Note Type 

Created By 

ARMS Msg 

07/01/2001 
1:22PM 

Reservation Created 

Res 

System 

System 

Sent 

07/02/2001 
2! 22PM 

Does not like red cars. This shows the first two lines of the 
notes section.(2 @ 45 char) 

Open 

System 

System 

Sent 

07/03/2001 
3i22PM 

Car is at Joe's Garage 

Close 

Callback 

ECARS 2.0 User 



Records Found: 3 



r* 
* ti 



; — ' •■ 1 7^ - - ;-. ~^"^r^v£*~ ; 

>pne . . ; - . 


Print All N otes re port look 
Figure 4 - Print All Records 


3. 
3.1 

3.11 


Notes (Figure 1 - Notes) 
Type 

Behavior 

is a drop down field cont 



The default value is "Air. The summary list is filtere d hv the item alerted from the values list. The 
Status drop down list should be taken into consideration when filtering the summary list. 


3.12 Validation 

No validation is necessary. 

3. 13 Business Exceptions 

None have been identified at this time. 

3.1.4 System Exceptions 

None have been identified at this time. 
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3.2 Status 

3.2.1 Behavior 

This is a drop down field containing the following dom ain values: 

• AU 

• Reservation 

• Open 

• Close 

The default value is "Air. The summary list is filtered b v the item selected from the values list The 
Type drop down list should be taken into consideration when filtering the summary list. 

3.2.2 Validation 

No validation is necessary. 

3. 2. 3 Business Exceptions 

None have been identified at this time. 

3.2.4 System Exceptions 

None have been identified at this time. 

3.3 Summary List 

3.3.1 Behavior 

The result list, as describe in the use case, will have a static column display sequence. M 
columns need to have the capa bility to be sorted ascending and descending. The user selects a 
Reservation/ Ticket bv clicking on the hyp erlink associated with the desired data row. Ih§ 
summary list will be p o pulated wit h the latest note appearing first and the earliest note appearing 
last (descending order sorte d bv date/timel 

An elli pse f ...1 should be placed at the end of the note text field if the verbiage contained in the 
note exceeds 80 characters. 

The user must have the appropriate security to view/edit the Reservation/Ticket 
selected. 

This list contains the application standard for lists regarding sorting by column. 
The 4 ARMS Msg' column header does not directly translate for Germany; rather, 
it is 'ARMS'. 

3.3.2 Validation 

None have been identified at this time. 

3. 3. 3 Business Exceptions 

None have been identified at this time. 

3. 3. 4 System Exceptions 

None have been identified at this time. 

3.4 Button Line Area 

3. 4. 1 Print All Records button 

3.4.1.1 Behavior 

The Print Ail Records bu tton will essentially generate an html report and send it to the printer. This will 
allow the user to print the entire collection of notes associated with a reservation/ticket. This report will not 
be sent to the screen, it will only be sent to the printer. (See Figure 4 - Print All Records.) 

3.4.1.2 Validation 

No validation is necessary. 
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3.4.1.3 Business Exceptions 

None have been identified at this time. 

3.4. 1 .4 System Exceptions 

None have been identified at this time. 

3.4.2 Add Note button 

3.4.2.1 Behavior 

The Add Note button will display the Add Note scr een for data input. (See Figure 2 - Add Note.) 

3.4.2.2 Validation 

No validation is necessary. 

3.4.2.3 Business Exceptions 

None have been identified at this time. 

3.4.2.4 System Exceptions 

None have been identified at this time. 

3. 4. 3 Previous Button 

3.4.3.1 Behavior 

The Previous button will take the user to the Vehicle/Shop screen within the same transaction. 

3.4.3.2 Validation # 
No validation is necessary. 

3:4.3.3 Business Exceptions 

None have been identified at this time. 

3.4.3.4 System Exceptions 

None have been identified at this time. 

3.4.4 Next Button 

3.4.4.1 Behavior 

The Next button will take the user to the Drivers screen within the same transaction. 

3.4.4.2 Validation 

No validation is necessary. 

3.4.4.3 Business Exceptions 

None have been identified at this time. 

3.4.4.4 System Exceptions 

None have been identified at this time. 

3. 4. 5 Complete Button 

3.4.5.1 Behavior 

The Complete button will initiate a save of the transaction. All validations will be performed, returning any 
errors to the user. If there are no errors, the transaction is saved, and the user is returned to the Open Ticket 
home page. 

3.4.5.2 Validation 

No validation is necessary. 
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3.4.5.3 Business Exceptions 

None have been identified at this time. 

3.4.5.4 System Exceptions 

None have been identified at this time. 


4. Add Note (Figure 2 - Add Note) 

4.1 Note 

4.1.1 Behavior 

This is a free form text field in which the user may enter data. 

4.12 Validation 

There must be data present in order for the note to be saved. 

4. 1.3 Business Exceptions 

None have been identified at this time. 

4. 14 System Exceptions 

None have been identified at this time. 

4.2 Button Line Area - Add Note 

4.2.1 OK button 
4.2.1.1 Behavior 

If data is not present in the Notes text field the feedback message reads, "Please enter a Note if $electing to 
Save." Two options are presented. OK and Cancel. Ok will take the user back to the Add Note screen for 
data entry. Cancel will dismiss the Add Note screen. 

Ok will be the default selection. 

The application saves the Date/Time. Status. Type. Note text and Created Bv data at the time the note is 
committed to the database. 


Status = reservation/ticket status as of note creation 

4.2.1.2 Validation 

There must be data present in the Notes 

4.2.1.3 Business Exceptions 
None have been identified at this time. 

4.2.1.4 System Exceptions 

None have been identified at this time. 

4.2.2 Cancel button 
4.2.2.1 Behavior 

/ill dismiss the Add Note 
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4.2.2.2 Validation 

If data has been entered the following f eedback me ssage is displayed: "Are vou sure vou want to exit and 
lose the entered information?". Two o ptions are presented. Yes and No. Yes will dismiss the screen and 
not save the data. No will take the user back to the Ad d Note screen. 

The default button selection is "No". 

4.2.2.3 Business Exceptions 

None have been identified at this time. 

4.2.2.4 System Exceptions 

None have been identified at this time. 

5, View Note (Figure 3 - View Note) 

This is a read only screen . 

5.1 Data 
5.1.1 Behavior 

This is a listing of the values associated with the selected note, this includes; 

• Date/Time 

• Status 

• Type 

• Created By 

• Arms Message Status t 

• Note text 

The Note text field should be l arge enou gh to display the e ntire 510 characters as defined in the database. 

5.12 Validation 

No validation is necessary. 

5. 1.3 Business Exceptions 

None have been identified at this time. 

5. 1.4 System Exceptions 

None have been identified at this time. 

5.2 Button Line Area - View Note 

5.2.1 Print button 

5.2.1.1 Behavior 

This button will essentially print a scre en print of t he View Note screen . 

5.2.1.2 Validation 

No validation is necessary. 

5.2.1.3 Business Exceptions 

None have been identified at this time. 

5.2.1.4 System Exceptions 

None have been identified at this time. 

5.2.2 Close button 
5.2.2.1 Behavior 

This button will dismiss the View Note screen . 
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5.2.2.2 Validation 

None have been identified at this time. 

5.2.2.3 Business Exceptions 

None have been identified at this time. 

5.2.2.4 System Exceptions 

None have been identified at this time. 


6. 
6.1 

6.2 


Rules 

Required Fields 

The Note text field is required for creating a note. Feedback m essages will be presented, as defined 
previously inthisdocu; 

Saving 

A note must be defined before the data can be saved to the d 


7. Security 

The user must have the appropriate security level to access this screen 
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Screen Action Specification 


1, Introduction 


This document will describe the behavioral characteristics associated with the Open Ticket Search screen, 
and its related screens. 

presentatio n as well as an v field formatting applicable to that particular locale. 


2. 


Screen Print 


I 'J Enterprise® ECARS Application - Microsoft Internet Explorer provided by Enterprise Rent-a-Car E3 1 



' Tools ' Help 


m 





Open Ticket Search 

h , 
ft f 

j Group: 

Branch: 


Advanced Search 


.. „ 

M |ALL 







V ! * 
1 r ' 

j Ticket Number: 

Renter Last Name: 

Renter First Name: 

Renter Telephone Number: 

t * 
*j " 


L.„ 

L 



I 




i ;„: 





■ —i 


V;, 


< o< 
' i - 


i.r f 


> > < < 


Figure 1 - Initial Entry - Simple Search 
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3 Enterprise® ECARS Application - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 


Open Ticket Search 


^^^^^^ 


: Group: 

I j 01 r ST LOUIS 


_ Branch; 

jH j LADUE F^^AL 01 01 


Advanced Search 


Ticket Number: 


Renter Last Name: 

|a : : 


Renter First Name: 

I 


Renter Telephone Number: 



! jjpi 

» w ' Renter Name ' 








| 0101 

AQUIUNO, 
BEATRICE 

2022543525 

30622C8G6WXH3WSSURLZV04 

02/O3/200 1 

ALLSTATE INS- 
ST. LOUIS** 

3HXW6G 



1 0101 

AQUIUNO, 
BEATRICE 

2022543525 

30S22C8G6WXH3WSSURLZY04 

02/03/2001 

ALLSTATE INS- 
ST, LOUIS** 

3HXW6H 



| 0101 

AQUILINO, 
BEATRICE 

2022543525 

3O622C806WXH3WSSURLZVO4 

02/03/2001 

ALLSTATE INS- 
ST. LOUIS** 

3HXW6I 


1 

i! 
II 










.Items 1-3 of 3 found 


First Prev 1 Next Last 


ri i 


Figure 2 - Simple Search with Search Results 
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|3 Enterprise^ ECARS Application 

Microsoft internet Explorer provided by Enterprise Rent-a-Car 

series! 



iiifiMsiiisiP 

[Open Ticket Search H 

{ Group: 

Branch: 

Simple Search 

(ALL _ 

... j3 [all _ *J 


I Ticket Number: 


Renter Last Name: 


Renter First Name: 


\ RO/PO/C!aim Number: 

II _ 


Unit Number: 


r 


Unit Plate Number: 


® Bill-To/Shop Name C Bili-To/Shop Number 


Renter Telephone Number: 


Open Ticket Date: 


IIS 


'is 

! I** 


Figure 3 - Advanced Search 
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3 Enterprise® ECARS Application 

■ Microsoft Internet Explorer provided by Enterprise Rent-a-Car 
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Open Ticket Search | 

Group: 

Branch: 

Simple Search 

j 01 - ST LOUIS 

lJLADUEREOTAL_Oiqi ^ ?j 


H Ticket Number: 


Renter Last Name: 


Unit Number: 


!|I 

I RO/PO/Cfaim Number: 

jl 

I <? Bill-To/Shop Name C Bi!l-To/Shop Number 


Renter First Name: 


Unit Plate Number: 


Renter Telephone Number: 
Open Ticket Date: 

I i 


I » 
! * % 4 








1 0101 

AQUIUNO, 2022543525 
BEATRICE ^2543523 

3O622C8<36WXH3WSSURLZV04 
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ALLSTATE INS- 
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£f 
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AQUILINO, 2022543525 
BEATRICE ZOZ2543525 

30622C8G6WXH3WSSURLZY04 

02/03/2001 

ALLSTATE INS- 
ST. LOUIS** 

3HXW6I 








> 
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Figure 4 - Advanced Search with Search Results 
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Figure 5 - Calendar selection 


3. Group 
3.1 Behavior 

This search criterion will be limited to active rental groups. The selection of " All" is also 
included, and will appear at the top, or first, in the list . This search criteria area will be a 
drop-down box. The users would also like to have the ability to type a character, alpha or 
numeric, into the criteria area and have the drop down list position to the character. (If 
the user enters an "H" the drop down list would position to the first string beginning with 
"H" in the list) The default item should be the group associated to the terminal locale . 
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3.2 Validation 

The items appearing in the list are static; the user cannot add items to the list 
dynamically. 

3.3 Business Exceptions 

The user should not be allowed to view or select a group outside of security parameters. 

3.4 System Exceptions 

None identified at this time. 

4. Branch 

4.1 Behavior 

This search criterion will be limite d to active branches The selection of "AH" is also included, and will 
appear at the top, or first, in the list. This search criteria area will be a drop-down box. The users would 
also like to have the ability to type a character, alpha or numeric, into the criteria area and have the drop 
down list position to the character . (If the user enters an "H" the drop down list would position to the first 
string beginning with "H" in the list) 

The default item should be the branch associated to the terminal locale . Branch items appearing in the list 
will be limited to the Group item selected. Once the selected Group item has changed, the first item (All) 
will be the default selection item. 

4.2 Validation * 

The items appearing in the list are static; the user cannot add items to the list 
dynamically. 

4.3 Business Exceptions 

The user should not be allowed to view or select a branch outside of security parameters. 

4.4 System Exceptions 

None identified at this time. 

5. Ticket Number 

5.1 Behavior 

This search area will be an alphanumeric field. It will return exact matches for the characters entered . 
When this search criterion is used, anv other entered criteria will be ignored bv the system. Alphanumeric 
values will be accepted into this field. 

5.2 Validation 

None identified at this time. 

5.3 Business Exceptions 

None identified at this time. 

5.4 System Exceptions 

None identified at this time. 

6. Renter Name Last / First 

6.1 Behavior 

This search criteria area will be an t ext field cont aining an i mplied wildca rd after the entered criteria , Ihg 
First Name field wil l not be enabled un til search criteria has been ent ered into the Last Name field. Thus. 
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the First Name field will not be accessible via either the ta b key or the m ouse unless Last Name data k 
present. 

It should be noted that either Last Name or Last Name and First Name used in 
combination, is considered to be just one search criteria. 

It will return exact matches for the characters entered and will continue with other text 
strings that match the characters entered, but are of a longer length (an implied wildcard). 
Example: If the Last Name search criteria entered were "Smith", you would receive back 
every open ticket with "Smith" in the Last name. You would also receive every character 
string that matched "Smith" for the first 5 characters, but was longer than five characters. 
Given this, you would also receive, "Smither", "Smithson", "Smithy", etc. These longer 
character matches would be alphabetically ascending after the exact character matches of 
equal length. The First Name field behaves in the same manner. 

6.2 Validation 

None identified at this time. 

6.3 Business Exceptions 

None identified at this time. 

6.4 System Exceptions 

None identified at this time. , 

7. Renter Tele phone Number 

7.1 Behavior 

This search criteria area will be an alphanu meric field. It will not be formatted for p resentation purposes. 
Returns ex act match es for the characters entered . A phone number is considered to be the entire number 
including area code. Example: In the United States, it would be the 3 digit area code, plus the seven digit 
phone number. (Country Code is not considered a part of the phone number.) The search will be on all 
phone number fi elds associated with the Driver/Renter. Currently, these are Home. Office and Other. 

7.2 Validation 

None identified at this time. 

7.3 Business Exceptions 

None identified at this time. 

7.4 System Exceptions 

None identified at this time. 

8. RO/PO/Claim Number 

8.1 Behavior 

This search crite ria area will be an alp ha numeric field. 
Returns exact matches for the characters entered . 

8.2 Validation 

None identified at this time. 

8.3 Business Exceptions 

None identified at this time. 
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8,4 System Exceptions 

None identified at this time. 

9. Unit Number 

9.1 Behavior 

This search criteria area will be an alphanumeric field. 
Returns exact matches for the characters entered . 

9.2 Validation 

None identified at this time. 

9.3 Business Exceptions 

None identified at this time. 

9.4 System Exceptions 

None identified at this time. 

10. Open Ticket Date 

10.1 Behavior 

Only numeric values will be accepted into these areas. The search to the data base will be 
an exact numeric, time stamp match . Associated with this field, is a? calendar function 
that allows the user to select a date from a calendar screen, or similar feature, instead of 
entering a value (Figure 5 - Calendar selection). Clicking on the calendar icon will 
display the screen, once a date is selected from the screen the Open Ticket Date field will 
be populated with the appropriate date. 

Returns exact matches for the characters entered. It will not be formatted for presentation purposes. The 
user may enter delineating characters, but these will be stripped out before searching the database to find an 
exact date match. 

10.2 Validation 

None identified at this time. 

10.3 Business Exceptions 

None identified at this time. 

10.4 System Exceptions 

None identified at this time. 

11. Unit Plate Number 

11.1 Behavior 

This search criteria area will be a n al phanumeric field. 
Returns exact matches for the characters entered. 

11.2 Validation 

None identified at this time. 

1 1 .3 Business Exceptions 

None identified at this time. 
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1 1 .4 System Exceptions 

None identified at this time. 

12. Bill-To/Shop Name/Number Group 

This group of controls includes the Bill-To/Shop Name and the Bill-To/Shop Number 
radio buttons as well as a criteria text box. 

12.1 Behavior 

This search criteria area will be an alphanumeric field regarding the text field. The Bill- 
To/Shop Name radio button will be the default selection upon screen entry . 
When the Bill-To/Shop Name radio button is selected an implied wildcard will be added 
at the end of the entered search criteria. Example: If the Bill-To/Shop Name search 
criteria entered were "Smith", you would receive back every open ticket with "Smith" in 
the Bill-To/Shop name. You would also receive every character string that matched 
"Smith" for the first 5 characters, but was longer than five characters. Given this, you 
would also receive, "Smither", "Smithson", "Smithy", etc. These longer character 
matches would be alphabetically ascending after the exact character matches of equal 
length. 

When the Bill-To/Shop Number radio button is selected it returns exact matches for the 
characters entered. i 
An entry into this field will search the Bill-To and Shop roles that an account (customer) 
may be and return all matches. Currently, the roles to which the search may be applied 
are "Shop" and "Bill-To". 

12.2 Validation 

None identified at this time. 

1 2.3 Business Exceptions 

None identified at this time. 

1 2.4 System Exceptions 

Only one radio button can be selected at a given time. 

13. Search Results Area 

13.1 Behavior 

The result list will have a static column display sequenc e . All columns need to have the capability to be 
sorted, asce nding and descending . The user selects an Open Ticket by clicking on the hyperlink associated 
with the desired data row. 

The user must have the appropriate security to view/edit the open ticket selected. 

13.2 Validation 

None identified at this time. 

13.3 Business Exceptions 

None identified at this time. 

13.4 System Exceptions 

None identified at this time. 
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14. Advanced Search / Simple Search hyperlink 

14.1 Behavior 

By clicking on the Advanced Search hyperlink, the user is presented with the advanced 
search functionality (Figure 3 - Advanced Search). Alternatively, by clicking on the 
Simple Search hyperlink, the user is presented with the default search screen (Figure 1 - 
Initial Entry - Simple Search). Anv search criteria entered when on the default search 
screen will be passed to the Advanced Search screen if/when accessed , If the user 
navigates to the Simple Search screen from the Advanced Search screen, any search 
criteria entered into the advanced criterion that is not found on simple search will be lost. 

14.2 Validation 

None identified at this time. 

14.3 Business Exceptions 

None identified at this time. 

14.4 System Exceptions 

None identified at this time. 

15. Results Feedback Line Area 

15.1 Behavior # 

This feedback area provides the user with the search result list count as well as list 
navigation. The user may select the block of records available as returned by the invoked 
search criteria. These blocks are identified by sequential numbers, along with a First (1 st 
block of records) and Last (last block of records). Also appearing will the Prev and Next. 
When negotiating through the result list the sequential numbers will change depending 
upon the block of records being viewed, other blocks of records can be accessed via the 
Prev and Next hyperlinks. For example looking at the Figure 2 - Simple Search with 
Search Results if the user selected Next, the sequential numbers listed will range from 2- 
6. If the user wishes to return to record block 1, they can either select First or Prev to 
view record blocks 1-5 again. 

15.2 Validation 

None identified at this time. 

15.3 Business Exceptions 

None identified at this time. 

15.4 System Exceptions 

None identified at this time. 

16. Button Line Area 

16.1 Behavior 

The Search image/button will invoke the search process, submitting the form to the 
server. The search can be invoked bv clicking on the button or the user using the enter 


Confidential 


©Enterprise Rent-A-Car, 
2000 


Page 13 


ECARS2 

<document identified 


Version: <1.0> 

Date: <dd/mmm/yy> 


The Reset control will ret urn the screen to its default state. The default state being 
search criteria controls blank, group/branch default to terminal locale and an empty result 
area. 

The system should determine that no more than the set limit of three search criteria have 
been entered. 

16.2 Validation 

None identified at this time. 

16.3 Business E xceptions 

A limit of three search criteria may be entered. 

If Ticket Number is entered, all other search criteria are ignored . 

16.4 System Exceptions 

If more than three search criteria are entered the user should be presented with a feedback 
message stating "A limit of three search criteria may be entered, Please refine your 
search." 

17. Rules 

The Renter Name Last / First and Account Name search criteria have an implied wild card character placed 
directly after the entered text, all other search criteria fields on this screen are to be treated as exact matches 
with searching. 

The user may invoke the search without changing or adding any search criteria to the default screen entry 
criteria. The user may increase the scope of the search by selecting all groups and/or all branches, no 
detailed search criteria is necessary when using this screen. 

There is a limit of three search criteria on which a search may be executed. This does not include the Group 
and Branch selections. If more than three are entered the system will present to the user an appropriate 
feedback message stating that a maximum of three search criteria may be entered. This message will be 
displayed a form submittal 

When there are not any matches to the input search criteria the user should be presented with a feedback 
message stating no items were found. This text should appear in the 0 listed below. 

1) If the search returns more open tickets than can be displayed on the screen at one time, then the 
system needs to present to the user the range of records they are viewing out of the total number of 
records 

All of the following search criteria, EXCEPT Ticket Number, will be limited to, or constrained by, the 
Group and Branch indicated or selected. 

18. Security 

The user must have the appropriate security level to access this screen. 


Confidential 


©Enterprise Rent-A-Car, 
2000 


Page 14 


Enterprise Rent-A-Car 


1=5: 

W 
tea? 


ECARS 2.0 - Open Ticket without Payment 

Screen Action Specification 


W Version <1.0> 


is? t 

'Is: J 
Lis 


ECARS2 


Version: 


<1.0> 


Date: 12/4/2001 


Revision History 


Date 

Version 

Description 

Author 

12/04/2001 

1.0 

Created document 

Marty Tichy 














Confidential 


©Enterprise Rent-A-Car 5 
2000 



Version: <1.0> 

ECARS 2 

Date: 12/4/2001 

i aoie ot contents 


1. Introduction 

4 

2. Screen Prints 

5 

3. Driver 

6 

3.1 Driver 

6 

3. LI Behavior 

6 

3.1.2 Validation 

7 

3. 1 .3 Business Exceptions 

7 

3. 1 .4 System Exceptions 

7 

4. Additional Driver 

7 

4. 1 Additional Driver 

7 

4.1.1 Behavior 

7 

4.1.2 Validation 

8 

4. 1 .3 Business Exceptions 

8 

4. 1 .4 System Exceptions 

8 

5. Complete 

8 

5.1 Form 

* 8 

5.1.1 Behavior 

8 

5.1.2 Validation 

8 

5. 1 .3 Business Exceptions 

8 

5 . 1 .4 System Exceptions 

8 

o. Kuies 

o 
0 

6. 1 Recuired Fields 

8 

6.2 Saving 

9 

7. Security 

9 


Confidential 


©Enterprise Rent-A-Car, 
2000 




ECARS2 

12/21/2001 


Screen Action Specification 

1. introduction 

This document will describe the behavioral characteristics associated with the Open Ticket without 
Payment Use Case. This document also extends the screen action specification documents associated with 
the reservation iteration, which includes the following screens: 

• Driver 

• Additional Driver 

• Other Address 

• Insurance Detail 

• Cash Qualification 

• Referral 

• Bill-To 

• Vehicle / Shop 

• Dates / Rates 

• Notes 

• Application Locking 

The user enters the new ticket process via the menu Tickets:New. This process behaves in the same 
manner as the previously defined Reservation process, opening a new record as an open ticket rather than a 
reservation. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 
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2. Screen Prints 


3 E3846G 0101 Enterprise* ECARS Application - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 


bhsbi 


DRIVERS 


REFERRAL 


DATES/RATES: 


-BILL-TO 


VEHICLE/SHOP 


NOTES 


Notes Taken : 1 


Tkt -139VC2 


• . t t, f 1 


Drh/er 


Renter 



Driver *• 


Othgr Address 


Insurance Detail 


Cash Qualification 


r Driver Name and Address - 


Last Name:* 

I 

-Phone Numbers - 
Home: 


First Name: 


Work: 


Extension: 


r 


Employer: 


Other Phone and Type: 

l -I" 


r- Home Address- 


Address: * 



ZIP: * 

Country: * 

r 9i U NITED STATj 

City: * 

State: * 

1 _ 



-Drivers License 


license Number: 

Expiration 
Date: * 

Issuing Country: 

i 

State 
Issued: * 

] UNITED STATU 

1 1 

SSN: * 

Date of Birth: 

* 

: 

Eye Color: * 

1 4 

Height: * 

Hair Color: * 

Weight: * 

1 J 1 


Primary Payment Method: 


i 5; 
• 1" t. 



Figure 1 - Driver 
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-5 E3846G 0101 Enteipiise© ECARS Application - Miciosoft Internet Explorei provided bji Enteiprise Rent-a-Cat 


flitters. | caiiDacKs - 1 vemcte f iqois ^ ( Help fx j 


| Additional Drivers; 1 



Other Address 


Insurance Detail 



BILL^TO' 


VEHICLE/SHOP 


Notes Taken : 1 


Tkt -139VC2 


Last Name:* 


First Name: * 


r Drivers License 

Expiration 
License Number: Date: 


r Phone Numbers - 
i Home: 


Work: 


Extension: 


Employer: 


r~ — — 

Other Phone and Type: 

I T~~l 


r Home Address- 


ee Same as Renter 

Address: 




ZIP: 

Country: 


(united statJI 

City: 

State: 



i T— 

Issuing Country : 
|lJNITED_STATj} 


SSN: 


Date of Birth: 


C 


Eye Color: 


Hair Color: 


Height: 

cm 

Weight: 


Credit Card Number 


r 


Credit Card Type 


Credit Card First Name 

L 

CC Expiration Date 


Credit Card Last Name 


5 ^s^fi 


% 

m 


w 

h 


Figure 2 - Additional Driver 


'at Complete - Web Page Dialog 


Complete 


;■ Complete 

I; C Complete - Unit Pend 

!• O Complete - Pre-Write 


Figure 3 - Complete 

3. Driver 

3.1 Driver 

3.1.1 Behavior 

This screen primarily behaves in the same manner as in Reservation, The following fields are 
this process: 

■ Last Name 

■ First Name 
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Country 
City 
State 

License Number 
Expiration Date 
State Issued 
Date of Birth 
Social Security Number 
Height 
Eye Color 
Weight 
Hair Color 

All conditionally required fields and behaviors defined during the Reservation iteration apply 

3.12 Validation 

No validation is necessary. 

3. 1 3 Business Exceptions 

None have been identified at this time. 

3. 1.4 System Exceptions 

None have been identified at this time. 

4. Additional Driver 
4.1 Additional Driver 

4.1.1 Behavior 

This screen primarily behaves in the same manner as in Reservation. The follow in g fields are required for 
this process: 

• Last Name 

• Date of Birth 

The following fields are conditionally required for this process: 

• If License Number is entered then 

■ State Issued 

■ Expiration Date f Drivers License section) 

• If Address is entered then 


- 2g 

■ Country 

■ CM 

■ State 
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All conditionally required fields and behaviors defined during the Reservation iteration apply. 

4. 1.2 Validation 

No validation is necessary. 

4. 1.3 Business Exceptions 

None have been identified at this time. 

4. 1.4 System Exceptions 

None have been identified at this time. 

5. Complete 

The complete process primarily behaves in the same manner as that defined in the Reservation iteration 
with the exception of the items listed below. This includes confirmation dialogs and validations. 

5.1 Form 

5.1.1 Behavior 

Only one selection can be made. The default section will be "Complete". 

The OK button will invoke the validation and save process. 

The Cancel button will dismiss the form, placing the user back to where they invoked the process. 

5.1.2 Validation 

Pomplete - When this op tion is selected all validations are invoked. This includes.the required fields 
HefmeH in the Driver 3rd Additional D r iver sections above as well as those conditionally required fields 
and validations Hefmed in the Reservation iterat i on Burin? this iteration of the Open Ticket project a 

OsM ML cgBogt he smed >« thh fn fh " tTnh Ptmd di,f(l ^ se " hed Mow ' Th ™ dttrm 

*hi< iteration a t jrbrt ran he save * i» CnmnietP - Pro-Write nr Complete- Unit-Pettd St(ltUS flfffo 
replete - I Init-Pend - When this optio n is selected all validations excen t those '"^^' ^^"^"" '^ 

h*in„ used these will he nJHod to the nat e ^t^ in future iterations of the Open Tim 


replete. - Pre-Wr ite ■ When this option is selected the Drivers I .ast and First names alone with the 
Rillin g Cycle from the Dates/Rates s c reen and only those, validations that are conditional required 
information are invoked. These sets of validations are primarily defined in the Reservation use cases. 

if the user selects to save a ticket and it fails the necessary validation, the system will provide a feedback 
message listing the offending items The user will then he allowed to save the ticket in a "lesser" open 
ticket status via the "Complete" button. 

5.13 Business Exceptions 

None have been identified at this time. 

5. 1 4 System Exceptions 

None have been identified at this time. 

6. Rules 

6.1 Required Fields 

Since this document is an extension of the screen action specification document defined in the Reservation 
and Open Ticket projects, the required fields and conditionally required fields along with all of the 
associated validations pertain to this document as well. 
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6.2 Saving 

The save is completed when the user saves the ticket. When the ticket saves successfully the application 
will navigate to the Ticket Search screen. 

7. Security 

The user must have the appropriate security level to access the screens. 
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22.1 Behavior 26 

22.2 Validation 2 ° 

22.3 Business Exceptions 2 ^ 

22.4 System Exceptions 26 
None identified at this time. 26 


26 
26 


23.2 Validation 26 
23.3 . Business Exceptions 2 ^ 


26 

26 

26 
27 
27 
27 


25. Billing Cycle Drop Down 

25.1 Behavior 

25.2 Validation 

25.3 Business Exceptions 

25.4 System Exceptions 
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26. Car Class to Charge for Drop Down 27 

26.1 Behavior 27 

26.2 Validation 28 

26.3 Business Exceptions 28 

26.4 System Exceptions 30 

27. Unit/Vehicle Input Search Area 30 

27.1 Behavior 30 

27.2 Validation 31 

27.3 Business Exceptions 3 1 

27.4 System Exceptions 3 1 

28. Units Available Search Button Function 3 1 

28.1 Behavior 31 

28.2 Validation 32 

28.3 Business Exceptions 32 

28.4 System Exceptions 32 

29. Get Rates Button 32 

29.1 Behavior * 32 

29.2 Validation 32 

29.3 Business Exceptions 32 

29.4 System Exceptions 32 

30. Rate Plan - Pop-Up Display Area 32 

30.1 Behavior 32 

30.2 Validation 33 

30.3 Business Exceptions 33 

30.4 System Exceptions 33 

3 1 . Rate Plan - Display Area 33 

31.1 Behavior 33 

31.2 Validation 34 

3 1 .3 Business Exceptions 34 

3 1 .4 System Exceptions 34 

32. Coverages Area 34 


32.1 Behavior 


32.4 System Exceptions 


33. 


34 


32.2 Validation 35 

32.3 Business Exceptions 3 ^ 


35 


Coverages - CD W Area 3 5 

33.1 Behavior 35 

33.2 Validation 35 
333 Business Exceptions 35 
33.4 System Exceptions 35 
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34. Coverages - PAI Area 35 

34.1 Behavior 35 

34.2 Validation 36 

34.3 Business Exceptions 36 

34.4 System Exceptions 36 

35. Coverages - SLP Area 36 

35.1 Behavior 36 

35.2 Validation 36 

35.3 Business Exceptions 3 6 

35.4 System Exceptions 36 

36. Cancel Function Button 36 

36.1 Behavior 36 

36.2 Validation 37 

36.3 Business Exceptions 37 

36.4 System Exceptions 37 

37. Error Message - Session Already Exists for this Browser Instance 37 
37.1 Behavior * 37 

38. Security 37 
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Screen Action Specification 

1 . Introduction 

This document will describe the behavioral characteristics associated with the Open Ticket Retrieve Rate(s) 
screens. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 


2. Open Ticket Retrieve Rates - Screens 


Aj| Rales New - MiciosoH Internet Exploiei piovided by Enlerpiise Renl-a-Cai 


e 


Top portion of Rates panel 
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-5 Rates New - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 



s/Rates.html8RateSource 


4 " 


■a 

1 1 , 


drivers | Dates/Rates 


Driver summary 1 
Driver summary 2 j |- Select- 


- Options -J3[jjjjj 


REFERRAL 


Referral sum 1 
Referral sum 2 


DATES/RATES 


Dates summary 1 
Dates summary 2 


Bill-To summary l 
Bill-To summary 2 


VEHICLE/SHOP 


Vehicle/Shop 1 
Vehicle/Shop 2 

Notes summary 1 
Notes summary 2 


irUnit Information — 
Vehicle Preferences 


Unit* 


License Plate # 


Last6ofVIN 


2000 Chevrolet ImpalalCAR 


Class to Charge fori JSf 1111111 


r Coverages S CDW,PAI,SLP- 


-Rates 



j 15,99^ ]L 150 j JwjLSL I 179-99' 

[ 1500; [ 539, 

I q.15 r 


Tkt - 234567 [ Cbk - 363221 


i - '■ 


f if 
5' < ' 

: i 


Bottom portion of Rates Panel 
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^ Rafes New - Microsoft Internet Explorer provided by Enterprise Rent-a-Cai 


BSE 


SSf : - I SHwlraEL..-, ■ — — 



j^file7//r:/APFS£cars_^^ 




, , - - 


Reservation [ iPt^Si^^S^^^^ 



> 


LI 


31 r 
» W 


^5. 5 
jjjj 


L.i. 
..aw 


drivers J Dates/Rates 


I- Options-^ 


Driver summary 1 
Driver summary 2 


REFERRAL 


Referral sum 1 
Referral sum 2 


DATES/RATES 


Dates summary 1 
Dates summary 2 

Bill -To summary 1 
Bill-To summary 2 


VEHICLE/SHOP 


Vehicle/Shop 1 
Vehicle/Shop 2 

Notes summary i 
Notes summary 2 


-Pickup - 
Date: 


Time: 


10/04/2001 , 


- Return - 
Date: 


Time: 


9:00 AM ;g ||1 0/08/2001 IH |3.00PM 


Date 


Time 


)P Elco Chevrolet 


unt Number 


:al Type 


Billing Cyde 


1 


2i 


Last6ofVIN 


2000 Chevrolet Imoala ICAR . < , , , -* - tj f** 


Start Charges if Different pop-up box 


si 


f- 
H 

• s " 


Si! 
< 
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^ Rales New - Miciosofl Internet Explorei piovided by Enteipiise Rent-a-Car 


PI 


ill 


fssls 



drivers I Dates/Rates 


Driver summary 1 
Driver summary 2 jr-pickup 


- Options ->j| Qo j ><i 


REFERRAL 


Referral sum 1 
Referral sum 2 


DATES/RATES 


Dates summary 1 
Dates summary 2 

Bill-To summary 1 
Bill-To summary 2 


VEHICLE/SHOP 


Vehicle/Shop 1 
Vehicle/Shop 2 

Notes summary 1 
Notes summary 2 


Date: 
I {10/04/2001 



* 2000 Chevrolet Imoala ICAR. . , . . tV . , . ,„., f 


Res - 411781 


, Tkt - 234567 Cbk - 363221 





J*; 



Change Return Information pop-up box 
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^Reservation Dales and Rates Screen Spec - Microsoft Word 




Dnv«f summer) 1 
Dnwr suswidt-jf 2 

sefarral sum 1 


OATE.S/RATE& 


Dates summary i 
dates summary 2 


, I , , , j . , . I , , . 2 « ■ ■ i • • • 3 ■ • ■ i ■ * i 4 ■ • • i » • • 5 


C'Hivcrs I Rates/Dates. 



ir 


Rats Source ~ 
Accost *laars& 


Account Mumbar 


Rental Type 


il 



Corptjutu 0101 *2735iiBi» Sti.*i.< **0 63130 * 31-* t 27 < 


Nsrtes summary 1 
Mcie-s summary 2 


Cwr^t Ol02 SiJJO.lPfe. Wdtfwo* MO 60*40 45»*15« % 


d&uaa aSSM c« P ««* o:<* uoin«* stuais w *ww 'Of 

frreg*^** *^^ 1>*W«|*»* ,,„Q 


igSsig C«rMr«« OSO? 120 S Stt«l« MO 63:05 <OC0) DQO-Q.DOO || 

300 



it*''.' 



Account Search Display 
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'5 Bates New - Microsoft Interne! Explorer provided by Enleipiise Rent-a-Car 


BSE 



? 1ST 

1,4 


|1J 
111 


.Reservatior%f<^ 


drivers jDates/Rates 


Driver summary 1 i 
Driver summery 2 j-Pickup 


REFERRAL 


Referral sum 1 
Referral sum 2 


DATES /RATES 


Dates summary 1 
Dates summary 2 

Bill -To summary 1 
Bill-To summary 2 


VEHICLE/SHOP 


Vehicle/Shop 1 
Vehide/Shop 2 

Notes summary 1 
Notes summary 2 


33SS3 HB 11*1 H 



1999{Mercury 


2000 Cadillac 


2000fFord 


Cougar [Series L [BCAR jWl 3-527 jsatatl^uis -Lindell branch 


Catera 


2000 Chevrolet Impala 


!000 Chevrolet 


Senes N fcCAR DC13-539 tadue 


Explorer 


Series B. CCAR X22-398 tadue 


leries P DCAB. Y29-238 Brentwood Blvd. 



2000 Chevrolet Imoala ICAR . . „ s . , . t ^jj 


fSf Tkt-234567 fcbk - 363221 


Units Available pop-up box 


J 4c 
f ■ 


r 


h: 

- s 
s ? 
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^3 Rates New - Miciosoft Internet Explorer pjovided by Enterprise Rent-a-Car 



drivers J Dates/Rates 


Driver summary 1 
Driver summary 2 


REFERRAL 


Referral sum 1 
Referral sum 2 


DATES/ RATE 5 


Dates summary 1 
Dates summary 2 

Bill-To summary 1 
Bill -To summary 2 


VEHICLE/SHOP 


Vehicle/Shop 1 
Vehicle/Shop 2 

Notes summary 1 
Notes summary 2 


i -Select- 


Id 


-Unit Information — 
Vehicle Preferences 


Class 


9.99 


250 


ECAR 


FCAR 


SCAR 


LCAR 


15,99 ) 
20,99 j 


250 


250 


25.99 


250 


30.99 


250 


35.99 


250 


1^ 


e 


29.99 


500 


34.99) 


500 


39.99 


500 


44.99 


500 


49.991 


500 


54.995 


500 


99.99 


109.99 


209.99 


249.99 


309.99 


409.99 


Mileage 


2500 


2500 


2500 


2500 


2500 


2500 


2.991 


0.25 


3.99 


4.99 


5.99 


6.99 


7.99 


0.25 


0.25 


0.25 


0.25 


0.25 


• Charge 

-is 


I 
I 



fTkt - 23456 7 [ cbk -"363221 


fit 



Get Rates display area 
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'3 Bates New - Miciusoll Internet ExpJorei piovideti by Enteiprise Rent-a-Cai 


m 

5 ■ 9 
'.MX 


111 

M 



drivers iDates/Rates 


Driver summary 1 
Driver summary 2 


REFERRAL 


Referral sum 1 
Referral sum 2 


DATES/RATES 


Dates summary 1 
Dates summary 2 


BILL-TO 


Bill-To summary 1 
Bill-To summary 2 


VEHICLE/SHOP 


Vehicle/Shop 1 
Vehicle/Shop 2 

Notes summary 1 
Notes summary 2 


r Rates- 


r Coverages jgj CDW.PAI.SLP- 


Class to Charge fori 3 1 



15.99 s 


I 15 0 J 59.99 


| 750 | 179.99 ji 1500, | 5.99' | 0.15 T 


CDW__jgj 1999-59 jMcrrth^ [l2/22^2002_ |11:1SAM O^WTJ |l 2:25 PM I 

PAi gj |999.99 JvVeekly [12/22/2002 ; |21^5AM__ [12/25/20Q2 |8:45PM I | 


]SLP -51 [112.99 (Weekly |l 2/22/2002 j |$55PM_ ^ 2/25/2002_ [9.00PM 


r 




Tkt -"2*34567 | Cbk - 36322 1 ] 


Expanded Coverages display area 


hi 

1 4 s 

" i\ 
11 
hi 



3. Open Ticket Number 
3.1 Behavior 

This area shows the unique open ticket number that has been assigned to the newly created 
ticket. The ticket number is 6 alphanumeric characters long. 
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If another reservation or ticket is open, its reservation/ticket number will be displayed in this area 
as well. The user will have the ability to have up to 3 reservations/tickets open at a time. A 
hyperlink will be available on the reservation/ticket numbers of the reservations that are NOT 
currently being displayed. For the reservation/ticket that is currently displayed, the 
reservation/ticket number will not have a hyperlink available. This is to allow the user to navigate 
between the open reservations/ticket. 


. £ 
5 5 


3.2 Validation 

None identified at this time. 

3.3 Business Exceptions 


If the user tries to open a 4 th reservation, the system will display a message 
stating, "A maximum of 3 reservations/tickets may be displayed". 


3.4 System Exceptions 


None identified at this time. 


4. Pick Up Group and Branch Area 
4.1 Behavior 

This area will be defaulted to the terminal location group and branch. A group and branch are required and 
it will be displayed in the header information. 


IlJ 4.2 Validation 


1*1 None, it will correspond to the PeopleSoft determined values. 


4.3 Business Exceptions 

None identified at this time. 

4.4 System Exceptions 

None identified at this time. 

5. Pick Up Date Area 

5.1 Behavior 

This area will be an alphanumeric field. It will not be formatted for presentation purposes. 

The user may enter delineating characters, but these will be stripped out before writing to 

the database. There should be a calendar function available which would allow the user to 

select a date from a calendar icon, or similar feature, instead of entering a value. If the 

user selects a date from the calendar icons, it will be displayed in the date area formatted 

appropriately by the locale. (As determined for all locale specific formatting.) 

It should initially default to the current date. 

5.2 Validation 

It will be a valid month, day and year combination. 

5.3 Business Exceptions 

If the user enters or selects a Pick-up date which is prior to the current date, display a message 
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"Pick-up date is prior to current date. Is this correct?" 

If the user enters or selects a Pick-up date which is in the future, display a message "Pick-up date 
cannot be in the future." 

A pick up date is required. If it is blanked out, not input or selected, display a message "Must 
specify a pick-up date". 

5.4 System Exceptions 

If not a valid month, day and year combination, the normal date in error message should 
be displayed. 

6- Pick Up Time Area 

6.1 Behavior 

In locales where time is shown by AM PM designation: 

This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute and 
AM/PM designation, and a maximum of Hour Hour Minute Minute AM/PM designation.i.e. 945A, 
would designate 9:45 in the morning. A leading zero may precede the hour, but is not required 
and will be removed before saving to the database. The minutes must be^two numeric values. 
The AM/PM designation of "A" or "P" must also be indicated. The user may enter delineating 
characters, but these will be removed before saving to the database. 

In locales where time is shown by 24 hour designation: 

This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute, and 
a maximum of Hour Hour Minute Minute, i.e. 945 would designate 9:45 in the morning, 1425 
would designate 2:25 in the afternoon. A leading zero may precede the hour, but is not required 
and wiii be removed before saving to the database. The minutes must be two numeric values. 
The user may enter delineating characters, but these will be removed before saving to the 
database. 

It should initially default to the current time. 

6.2 Validation 

In locales where time is shown by AM PM designation: 

Time increments can range from 1200A to 1159A and from 1200P until 1 159P. If an entry is not 
within these two ranges display "Must specify a valid time". 

In locales where time is shown by 24 hour designation: 

Time increments can range from 0000 to 2400. If an entry is not within this range display "Must 
specify a valid time". 

6.3 Business Exceptions 

A pick-up time cannot be selected if there is not a pick-date selected. If this is attempted, 
display a message "Must specify a pick-up date". 

If the user enters or selects a Pick-up time which is prior to the current time, display a message 
"Pick-up time is prior to current time, is this correct?" 
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A pick up time is required. If the default value is removed, display a message 
"Must specify a pick-up time". 

It is possible to have a pick-up time in the future, but the pick-up date must be the same. 

6.4 System Exceptions 

None identified at this time. 

7. Pick Up Time Drop Down 

7.1 Behavior 

This drop down icon will display the time in 15-minute increments. When 
selected, it should be positioned to the % hour increment immediately preceding 
the current time and format according to the locale's format. 

7.2 Validation 

None identified at this time. 

7.3 Business Exceptions 

A pick-up time cannot be selected if there is not a pick-date selected. If this is attempted, 
display a message "Must specify a pick-up date". 

A pick up time is required. If the default value is removed, display a message 
"Must specify a pick-up time". 

If the user enters or selects a Pick-up time which is prior to the current time, 
display a message "Pick-up time is prior to current time. Is this correct?" 

It is possible to have a pick-up time in the future, but the pick-up date must be the same. 

7.4 System Exceptions 

None identified at this time. 

8. Start Charges if Different Button Function 
8.1 Behavior 

Selecting this function will present the user will a pop-up box showing date and time 
fields. Information entered in the pop-up box will be displayed under the Start Charges if 
Different button function. 
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8.2 Validation 

See specific areas. 

The ok feature will save date and time if valid. 

The cancel feature will close the pop-up and not save entered information, if any. 

8.3 Business Exceptions 

See specific areas. 

8.4 System Exceptions 

None identified at this time. 

9. Start Charges if Different Date Area 

9.1 Behavior 

This area will be an alphanumeric field. It will not be formatted for presentation purposes. 

The user may enter delineating characters, but these will be stripped out before writing to 

the database. There should be a calendar function available which would allow the user to 

select a date from a calendar icon, or similar feature, instead of entering a value. If the 

user selects a date from the calendar icons, it will be displayed in the date area formatted 

appropriately by the locale. (As determined for all locale specific foimatting.) 

It should initially default a blank. 

9.2 Validation 

It will be a valid month, day and year combination. 

9.3 Business Exceptions 

The start charges if different date must be greater than or equal to the pick-up date, and less than 
or equal to the return date. 

If the user enters or selects a start charges if different date which is prior to the Pick-up date, 
display a message "Start charges dates cannot be prior to pick-up date." 

If the user enters or selects a start charges if different date which is after the return date, display 
a message "Start charges dates cannot be after return date." 

9.4 System Exceptions 

If not a valid month, day and year combination, the normal date in error message should 
be displayed. 


10. Start Charges if Different Time Area 

10.1 Behavior 

In locales where time is shown by AM PM designation: 

This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute and 
AM/PM designation, and a maximum of Hour Hour Minute Minute AM/PM designation.i.e. 945A, 
would designate 9:45 in the morning. A leading zero may precede the hour, but is not required 
and will be removed before saving to the database. The minutes must be two numeric values. ^ 
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The AM/PM designation of "A" or "P" must also be indicated. The user may enter delineating 
characters, but these wiii be removed before saving to the database. 

In locales where time is shown by 24 hour designation: 

This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute, and 
a maximum of Hour Hour Minute Minute, i.e. 945 would designate 9:45 in the morning, 1425 
would designate 2:25 in the afternoon. A leading zero may precede the hour, but is not required 
and will be removed before saving to the database. The minutes must be two numeric values. 
The user may enter delineating characters, but these will be removed before saving to the 
database. 

It should initially default to blank. 

10.2 Validation 

in locales where time is shown by AM PM designation: 

Time increments can range from 1200A to 1 159A and from 1200P until 1 159P. If an entry is not 
within these two ranges display "Must specify a valid time". 

In locales where time is shown by 24 hour designation: 

Time increments can range from 0000 to 2400. If an entry is not within this range display "Must 
specify a valid time". 

10.3 Business Exceptions 

A start charges if different time cannot be selected if there is not a start charges if 
different date. If this is attempted, display a message "Must specify a start charges if 
different date". 

The start charges if different time must be greater than or equal to the pick-up time, if the start 
charges if different date is equal the pick-up date. 

The start charges if different time must be less than or equal to the return time, if the start 
charges if different date is equal the return date. 

If the start charges if different date is equal to the pick-up date and the user enters or selects a 
start charges if different time which is prior to the Pick-up time, display a message "Start charges 
time cannot be prior to pick-up time" 

If the start charges if different date is equal to the return date and the user enters or selects a 
start charges if different time which is after the return time, display a message "Start charges time 
cannot be after return time" 

10.4 System Exceptions 

None identified at this time. 
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1 1 . Start Charges if Different Time Drop Down 

11.1 Behavior 

This drop down icon will display the time in 15-minute increments. When 
selected, it should be positioned to the % hour increment immediately preceding 
the current time and format according to the locale's format. 

11.2 Validation 

None identified at this time. 

1 1 .3 Business Exceptions 

A start charges if different time cannot be selected if there is not a start charges if 
different date. If this is attempted, display a message "Must specify a start charges if 
different date". 

The start charges if different time must be greater than or equal to the pick-up time, if the start 
charges if different date is equal the pick-up date. # 

The start charges if different time must be less than or equal to the return time, if the start 
charges if different date is equal the return date. 

If the start charges if different date is equal to the pick-up date and the user enters or selects a 
start charges if different time which is prior to the Pick-up time, display a message "Start charges 
time cannot be prior to pick-up time" 

If the start charges if different date is equal to the return date and the user enters or selects a 
start charges if different time which is after the return time, display a message "Start charges time 
cannot be after return time" 

11.4 System Exceptions 

None identified at this time. 


12. Return Date Area 

12.1 Behavior 

This area will be an alphanumeric field. It will not be formatted for presentation purposes. 

The user may enter delineating characters, but these will be stripped out before writing to 

the database. There should be a calendar function available which would allow the user to 

select a date from a calendar icon, or similar feature, instead of entering a value. If the 

user selects a date from the calendar icons, it will be displayed in the date area formatted 

appropriately by the locale. (As determined for all locale specific formatting.) 

It should default to a blank area. 
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12.2 Validation 

It will be a valid month, day and year combination. 

12.3 Business Exceptions 

A return date is required. 

If the user does not enter a date a message is displayed "Return date must be specified". 

The return date cannot be before the pick-up date, if it is, display message "Return date must be 
equal to, or after Pick-up date". 

12.4 System Exceptions 

If not a valid month, day and year combination, the normal date in error message should 
be displayed 


13. Return Time Area 

13.1 Behavior 

In locales where time is shown by AM PM designation: 

This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute and 
AM/PM designation, and a maximum of Hour Hour Minute Minute AM/PMidesignation.Le. 945A, 
would designate 9:45 in the morning, A leading zero may precede the hour, but is not required 
and will be removed before saving to the database. The minutes must be two numeric values. 
The AM/PM designation of "A" or "P" must also be indicated. The user may enter delineating 
characters, but these will be removed before saving to the database. 

In locales where time is shown by 24 hour designation: 

This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute, and 
a maximum of Hour Hour Minute Minute, i.e. 945 would designate 9:45 in the morning, 1425 
would designate 2:25 in the afternoon. A leading zero may precede the hour, but is not required 
and will be removed before saving to the database. The minutes must be two numeric values. 
The user may enter delineating characters, but these will be removed before saving to the 
database. 

This should default to a blank area. 

13.2 Validation 

In locales where time is shown by AM PM designation: 

Time increments can range from 1200A to 1159A and from 1200P until 1 159P. If an entry is not 
within these two ranges display "Must specify a valid time". 

In locales where time is shown by 24 hour designation: 

Time increments can range from 0000 to 2400. If an entry is not within this range display "Must 
specify a valid time". 


13.3 Business Exceptions 

A return time is required. 

If the user does not enter a time a message is displayed "Return time must be specified . 
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A return time cannot be selected if there is not a return date entered or selected. If this is 
attempted, display a message "Must specify a return date". 

If the return date is the same as the pickup date, then the return time must be later than 
the pickup time* If not, display a message "When pickup and return date are the same, 
return time must be later than pickup time". 

13.4 System Exceptions 

None identified at this time. 

14. Return Time Drop Down 

14.1 Behavior 

This drop down icon will display the time in 15-minute increments. When 
selected, it should be positioned to the % hour increment immediately preceding 
the current time and format according to the locale's format 

14.2 Validation > 

None identified at this time. 

14.3 Business Exceptions 

A return time is required. 

If the user does not enter a time a message is displayed "Return time must be specified". 

A return time cannot be selected if there is not a return date entered or selected. If this is 
attempted, display a message "Must specify a return date". 

If the return date is the same as the pickup date, then the return time must be later than 
the pickup time. If not, display a message "When pickup and return date are the same, 
return time must be later than pickup time". 

14.4 System Exceptions 

None identified at this time. 

15. Change Return Location Button Function 
15.1 Behavior 

Selecting this function will present the user will a pop-up box that will show the default 
group, branch (to the terminal's location) and return method drop down listings and a 
return location text area. 

Only areas with changed information will be displayed under the Change Return 
Information button function. The terminal location default group and branch will NOT be 
displayed unless changes are made. 
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15.2 Validation 

See specific areas. 

There are not any required areas. 

The ok feature will save selected or entered information. 

The cancel feature will close the pop-up and not save entered information, if any. 

15.3 Business Exceptions 

See specific areas. 

15.4 System Exceptions 

None identified at this time. 

16. Change Return Location Group 

16.1 Behavior 

This drop down listing will be limited to those groups that exist at any point in time. The 
selection of "All" is NOT included in the list. The users would also like to have the 
ability to type a character, alpha or numeric, into the criteria area and have the drop down 
list position to the character. (If the user enters an "H" the drop down list would position 
to the first string beginning with "H" in the list) * 
This should default to the terminal location group. 

16.2 Validation 

The items appearing in the list are static; the user cannot add items to the list 
dynamically. 

16.3 Business Exceptions 

None identified at this time. 

16.4 System Exceptions 

None identified at this time. 

17. Change Return Location Branch 
17.1 Behavior 

This drop down listing will be limited to those branches that exist within the group at any point in time. The 
selection of "All" is NOT included in this selection list. The users would also like to have the ability to 
type a character, alpha or numeric, into the criteria area and have the drop down list position to the 
character. (If the user enters an "H" the drop down list would position to the first string beginning with 
"H" in the list) 

Branch items appearing in the list will be limited to the Group item selected. Once the selected Group item 
has changed, the branch will be set to blanks. This will require the user to select a branch, at which time the 
display area will be refreshed, repopulated and repositioned. 
This will default to the terminal location branch. 


17.2 Validation 

The items appearing in the list are static; the user cannot add items to the list 
dynamically. This list will be limited to the branches associated with the group selected. 
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17.3 Business Exceptions 

None identified at this time. 

17.4 System Exceptions 

None identified at this time. 


18. Change Return Location Method 

18.1 Behavior 

This drop down listing will be limited to values associated with the return method, 
currently the valid values are: Branch, Drop and Ride Back in North America and 
Branch, Ride Back and Automatic Pickup (APU) in Europe. 

18.2 Validation 

The items appearing in the list are static; the user cannot add items to the list 
□ dynamically. 

18.3 Business Exceptions 

None identified at this time. 
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18.4 System Exceptions 


I'W None identified at this time. 


19. Change Return Location Text Area 

19.1 Behavior 

This will be a free form text area. 

19.2 Validation 

None identified at this time. 

19.3 Business Exceptions 

None identified at this time. 

1 9.4 System Exceptions 

None identified at this time. 

20. Account Name Drop Down 
20.1 Behavior 

This area will be a drop down list of the Branch's short list, for North America. For 
everywhere else it will be the Group's Account list. If there are any of the 
following associated with the particular open ticket, they will appear at the top or 
beginning of the list in the following order. 
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1) Any Bill-To Accounts 

2) Any Referral Accounts 

3) Any Shop Accounts 

The information displayed about an Account will be in the following order: 

1) Account Name 

2) Account Number 

3) Rental Type 

4) Owning Group/Branch 

5) Address 

6) City 

7) State 

8) Zip 

9) Telephone 

The Account Name in the display area will have a hyper-link which, when 
selected, will populate the Account Name, Account Number, Account Type and 
Rate Plan areas on the Dates and Rates panel. 

20.2 Validation 

None identified at this time. 

20.3 Business Exceptions 

If Account name or number is selected and the following account types are determined, 
then other areas will be defaulted to the values shown. 


20.4 System Exceptions 

None identified at this time. 

21 . Account Number Area 

21.1 Behavior 

This area will allow entry of alphanumeric values. When there is a match, the system will populate 
the Account Name, Account Number, Account Type and Rate Plan areas on the Dates and Rates 
panel. The search will be executed as the user tabs off of the field. 

21.2 Validation 

None identified at this time. 
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21.3 Business Exceptions 

If there is not an exact match, then display a message "Account number does not exist." 

21 .4 System Exceptions 

None identified at this time. 

22. Account Search Button 

22.1 Behavior 

Selecting this button will display the account search panel. See Referral Source Supplementary 
Specification for details. 

22.2 Validation 

None identified at this time. 

22.3 Business Exceptions 

None identified at this time. 

22.4 System Exceptions 

None identified at this time. * 

23. Rate Plan Drop Down 

23.1 Behavior 

This area will be populated when an Account Name or Account Number has been selected. 
If th e r e are multiple plans associated with an Account, it will list all of the rate plans associated 
with that Account, and the user must choose one. When there are multiple rate plans, the value 
"select" will appear in area so the user knows that there are multiple rate plans and selection of a 
single one is required. 

If there is only a single rate plan associated with and Account then the rate plan pop-up box will 
appear show all of the car classes and rates associated with that account 

23.2 Validation 

None identified at this time. 

23.3 Business Exceptions 

If no rate plans are associated with an Account then a message is displayed "No rates were found". 

23.4 System Exceptions 

None identified at this time. 

24. Rental Type Drop Down 

24.1 Behavior 

This area will be a drop down list of Rental types. 

Rental Type 


Insurance 
Confidential 
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Bodyshop 

Dealership 

Retail 

Corporate 

Other 

Employee 

Government 

Fleet 

Truck 

Rideshare 

Walk-in 


Q 24.2 Validation 

Any value selected is valid. 


□ 24.3 Business Exceptions 

H None identified at this time. 


y, 24.4 System Exceptions 

Hi None identified at this time. 

hi 

25. Billing Cycle Drop Down 

25.1 Behavior 

This area will initially default to the billing cycle associated with the Account and Rate Plan 
selected. It may be changed to anther value. 
Drop down domain values are Blank, 24 Hour and Calendar Day. 

25.2 Validation 

None identified at this time. 

25.3 Business Exceptions 

See list in account name area for defaults, based on account. 


25.4 System Exceptions 

None identified at this time 

26. Car Class to Charge for Drop Down 

26.1 Behavior 

This area will be a drop down list that also allows entry of alphanumeric values. The drop down 
list will be comprised of the most commonly used car classes. The entry of alphanumeric values 
will be edited against a larger more comprehensive car class list If there is a successful 
vehicle/unit search, this will be populated with that particular vehicle's car class. It is possible to 
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change this value. 

Drop down list values 

Class and Type 

ECAR 

CCAR 

ICAR 

SCAR 

FCAR 

PCAR 

LCAR 

MVAR 

XFAR 

XPAR 

XXAR 

XVAR 


26.2 Validation 

None identified at this time. 

26.3 Business Exceptions 

If the values entered are not one of the ones listed below, a message is displayed "Must enter a valid car 
class". 

Car Class Edit List of Values 


Class and Type 

MCAR 

MBAR 

MDAR 

MXAR 

MSAR 

MTAR 

MWAR 

MVAR 

MFAR 

MPAR 

ECAR 

EBAR 

EDAR 

EXAR 

ESAR 
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ETAR 

EWAR 

EVAR 

EFAR 

EPAR 

CCAR 

CBAR 

CDAR 

CXAR 

CSAR 

CTAR 

CWAR 

CVAR 

CFAR 

CPAR 

ICAR 

I BAR 

IDAR 

IXAR 

ISAR 

ITAR 

IWAR 

IVAR 

I FAR 

I PAR 

SCAR 

SBAR 

SDAR 

SXAR 

SSAR 

STAR 

SWAR 

SVAR 

SFAR 

SPAR 

FCAR 

FBAR 

FDAR 

FXAR 

FSAR 

FTAR 

FWAR 

FVAR 
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FFAR 

FPAR 

PCAR 

PBAR 

PDAR 

PXAR 

PSAR 

PTAR 

PWAR 

PVAR 

PFAR 

PPAR 

LCAR 

LBAR 

LDAR 

LXAR 

LSAR 

LTAR 

LWAR 

LVAR 

LFAR 

LPAR 

XCAR 

XBAR 

XDAR 

XXAR 

XSAR 

XTAR 

XWAR 

XVAR 

XFAR 

XPAR 


26.4 System Exceptions 

None identified at this time. 

27. Unit/Vehicle Input Search Area 
27.1 Behavior 

This will be an alphanumeric input area, consisting of 3 areas. The Unit Number, the License 
Number and the last 6 Digits of the Vehicle Identification Number, (VIN). 
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The Unit Number must be entered, with at least one of the other two. Using this information, the 
system will be able to determine the associated car class, for the rate source selected. 
If there is only a single rate plan associated with the car class and rate source then the system 
will return rates for that particular unit/vehicle and the rates associated with all applicable 
coverages, PAI, CDW and SLP. 


If there is more than one rate plan associated with the rate source, then the system will display all 
rate plans determined by the car class and allow the user to select a single rate plan. After a 
single rate plan is selected, then the system will return rates for that particular unit/vehicle and the 
rates associated with all applicable coverages, PAI, CDW and SLP. 

At a minimum, we will need to return the associated Unit Number, Year, Make, Model and Car 
Class of the different vehicles. This information will need to be saved with the transaction also. 
It will also be displayed within the unit information box when retrieved The search will initiate when the 
user tabs off of the last field. 

27.2 Validation 

None identified at this time. # 

27.3 Business Exceptions 

If the unit/vehicle selected belong to a car class, which is not associated with a rate plan for the designated 
rate source, then a message is displayed "Rate plan does not contain selected car class". 
If the user has not entered one of the required fields, display a message "Unit number and license plate 
number or last 6 of VIN required. 

27.4 System Exceptions 

None identified at this time. 

At a minimum, we will need to return the associated Unit Number, Year, Make, Model and Car 
Class of the different vehicles. This information will need to be saved with the transaction also. 

28. Units Available Search Button Function 

28.1 Behavior 

Selecting this button will display the Units available search pop-up panel 

The pop-up box will display: 
Group and branch drop down boxes. 

Unit number, License plate number and Last 6 of VIN input areas. 

A search function which will execute the search 

A display of the vehicles available table with columns: 

Year, Make, Model, Series, Car Class, License Plate Number and Location. 

The Group and Branch drop down boxes will default to the terminal location. 

The Unit Number, License Plate Number and Last 6 of VIN, will default to blank. Any one, two or all three 
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may be used to search the Vehicle Data base. 

The vehicles available display will default display the available units at the terminal location default group 
and branch. 

28.2 Validation 

None identified at this time. 

28.3 Business Exceptions 

There must be at least one search criteria to execute a search, otherwise display a message "Must specify at 
least one search criteria". 


28.4 System Exceptions 

None identified at this time. 


u 29. Get Rates Button 


- 29-1 Behavior 


Selection of this button will have the system execute a search for rate plans associated with the information 
entered 


29.2 Validation 

None identified at this time. 

29.3 Business Exceptions 

At a minimum there must be an Account Name or an Account Number to search for rates. If the user 
$l selects this button without one of these a message is displayed "Must specify account name or number". 

29.4 System Exceptions 

None identified at this time. 

30. Rate Plan - Pop-Up Display Area 
30.1 Behavior 

This is a pop-up window that will display the rates of a rate plan associated with 
an Account. Information displayed is: 

Rate pop-up box columns and information: 

• Car Class 

• Daily - Rate and Mileage 

• Weekly - Rate and Mileage 

• Monthly - Rate and Mileage 

• Hourly - Rate 

• Mileage Charge 

Car class will have a hyper-link which will allow the user to select the rate they want. This will then 
populate the rates display area on the Dates and Rates panel. 
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30.2 Validation 

None identified at this time. 

30.3 Business Exceptions 

If an Account has more than one rate plan associated with it, then this 
information cannot be displayed until the Rate Plan area has a value. 

If an Account has a single rate plan associated with it, then this information is 
displayed after the Account Name is selected or an Account Number is entered. 

If an Account has a single rate plan and there is a value in the Car Class area, 
and that car class is in the rate plan, then the rates display area of the Dates and 
Rates panel is populated with the appropriate information and the rate plan pop- 
up window is NOT displayed. 

If an Account has multiple rate plans and there is a value in the Car Class area, 
and there is not a value in Rate Plan area, a message should display "Must 
specify a rate plan". , 

If an Account has a multiple rate plans, and there is a value in the Rate Plan area 
and there is a value in the Car Class area, and that car class is in the rate plan, 
then the rates display area of the Dates and Rates panel is populated with the 
appropriate information and the rate plan pop-up window is NOT displayed. 

If an Account has a single rate plans, and there is a value in the Car Class area, 
but that car class is not in the rate plan, then a message is displayed, "Rate plan 
does not contain selected car class". 

If an Account has a multiple rate plans, and there is a value in the Rate Plan area 
and there is a value in the Car Class area, but that car class is not in the rate 
plan, then a message is displayed "No rates found for car class selected". 

30.4 System Exceptions 

None identified at this time 

31 . Rate Plan - Display Area 
31.1 Behavior 

This is a display area that will be populated with the rates associated with a 
particular car class of a rate plan associated with an Account. 
Information displayed is: 

• Car Class 
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• Daily Rate 

• Daily Mileage 

• Weekly Rate 

• Weekly Mileage 

• Monthly Rate 

• Monthly Mileage 

• Hourly Rate 

• Mileage Charge 

• No Charge Check Box 

All of the information presented, except Car Class, has the ability to be edited or 
changed. 

There is an interaction between the Mileage Charge and the No Charge Check Box. If the 
No Charge Check Box is selected, then the Mileage Charge is set to zero and the area 
disabled. Unselecting the No Charge Check Box will enable the Mile Charge area for 
entering values. 


31.2 Validation 

None identified at this time. 

31.3 Business Exceptions 

Negative values may not be entered. If attempted, display message "Must specify positive 
amount" . 

31.4 System Exceptions 

None identified at this time 

32. Coverages Area 

32.1 Behavior 

This will be a collapsible/expandable area to display the different coverages. There will be some 
sort of button functionality which will allow this area to be expanded or collapsed. In either state 
the selected coverages will be listed to the side of the button function. Values within area may be 
changed or edited. 

Each area will have a drop-down box to be able to select additional items. 

It is anticipated that the information to be displayed for each instance of the coverage is: 
Description 
Rate 

Rate Frequency 
Start Date 
Start Time 
End Date 
End Time 

All of this information will come from what is maintained in the Perot systems. 
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32.2 Validation 

None identified at this time. 

32.3 Business Exceptions 

Negative values may not be entered in the rate area. If attempted, display message "Must 
specify positive amount". 

Dates may be changed, but cannot be beyond the Pick-up and/or Return date range. If 
this is attempted, display appropriate message, either "Start date cannot be before pick-up 
date" or "End date cannot be after return date". 

Similarly, Times may be changed, but cannot be beyond the Pick-up and/or Return time 
range. If this is attempted, display appropriate message, either "Start time cannot be 
before pick-up time" or "End time cannot be after return time". 


32.4 System Exceptions 

None identified at this time. 

33. Coverages - CDW Area 

33.1 Behavior 

This area will initially default to the amount of Collision Damage Waiver associated with the Car 
Class and Rate Plan for the particular Account This area may be changed or edited. 
Each area will have a drop-down box to be able to select additional items. 

33.2 Validation 

None identified at this time. 

33.3 Business Exceptions 

Negative values may not be entered in the rate area. If attempted, display message "Must 
specify positive amount". 

Dates may be changed, but cannot be beyond the Pick-up and/or Return date range. If 
this is attempted, display appropriate message, either "Start date cannot be before pick-up 
date" or "End date cannot be after return date". 

Similarly, Times may be changed, but cannot be beyond the Pick-up and/or Return time 
range. If this is attempted, display appropriate message, either "Start time cannot be 
before pick-up time" or "End time cannot be after return time". 

33.4 System Exceptions 

None identified at this time 

34. Coverages - PAI Area 
34.1 Behavior 

This area will initially default to the amount of Personal Accident Insurance associated with the 
Car Class and Rate Plan for the particular Account This area may be changed or edited. 
Each area will have a drop-down box to be able to select additional items. 
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34.2 Validation 

None identified at this time. 

34.3 Business Exceptions 

Negative values may not be entered in the rate area. If attempted, display message "Must 
specify positive amount". 

Dates may be changed, but cannot be beyond the Pick-up and/or Return date range. If 
this is attempted, display appropriate message, either "Start date cannot be before pick-up 
date" or "End date cannot be after return date". 

Similarly, Times may be changed, but cannot be beyond the Pick-up and/or Return time 
range. If this is attempted, display appropriate message, either "Start time cannot be 
before pick-up time" or "End time cannot be after return time". 

34.4 System Exceptions 

None identified at this time 


35. Coverages - SLP Area 

35.1 Behavior * 

This area will initially default to the amount of Supplemental Liability Protection associated with 
the Car Class and Rate Plan for the particular Account This area may be changed or edited. 
Each area will have a drop-down box to be able to select additional items. 

35.2 Validation 

None identified at this time. 

35.3 Business Exceptions 

Negative values may not be entered in the rate area. If attempted, display message "Must 
specify positive amount". 

Dates may be changed, but cannot be beyond the Pick-up and/or Return date range. If 
this is attempted, display appropriate message, either "Start date cannot be before pick-up 
date" or "End date cannot be after return date". 

Similarly, Times may be changed, but cannot be beyond the Pick-up and/or Return time 
range. If this is attempted, display appropriate message, either "Start time cannot be 
before pick-up time" or "End time cannot be after return time". 

35.4 System Exceptions 

None identified at this time. 

36. Cancel Function Button 
36.1 Behavior 

The Cancel image/button will take the user to the last panel accessed. 
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36.2 Validation 

None identified at this time. 

36.3 Business Exceptions 

None identified at this time. 

36.4 System Exceptions 

None identified at this time. 

General Requirements 

37. Error Message - Session Already Exists for this Browser Instance 

This captures the Error Message generated when the user attempts to open a new session 
on the terminal without opening a new instance of the IE browser. 

37.1 Behavior 

When the user attempts to open a new session on the same terminal without opening a 
new instance of the browser, display the following error message: 

"There is a session already open for this browser on this terminal. 
Please use that session or open a new browser." 

For Informational purposes: This situation can occur when the user attempts to open the 
active session by selecting the window titled "About" and uses the "back" button to 
navigate to the previous page. 

38. Security 

The user must have the appropriate security level to access these screens. The user is allowed to view or 
print anything. It is when they attempt to edit a reservation that their security restrictions will be enforced. 


Confidential 


©Enterprise Rent-A-Car, 
2000 


37 


Enterprise Rent-A-Car 


Rental Redesign/ECARS 2.0 
Screen Action Specification: Vehicle / Shop 

Version 2.7 


Rental Redesign 

Version: 2.7 

Screen Action Specification 

Date: 12/21/2001 

Vehicle / Shop 


Revision History 


Date 

Version 

Description 

Author 

08/03/2001 

1.0 

Created document 

Chris Carr 

08/07/2001 

1.1 

Updated document with revised screen 
shots and verbiage 

Chris Carr 

08/10/2001 

1.2 

Updated document to reflect Use Case 
changes 

Chris Can- 

08/13/2001 

1.3 

Clarification of Contact Last Name and/or 
Contact First Name. Added info relating to 
System generated Notes. 

Chris Can- 

08/14/2001 

1.4 

Added info for European Branch Short list 

Chris Can- 

08/16/2001 

1.5 

• Changed text in 4.5 . 1 to ". . . Account's 
phone number." 

• Changed text in 4.5.2 to "Entered data 
should be 10 digits for US to include 
area code or appropriate format for 
other countries." 

• Phone number is pre-populated with 

vain** from cplpptf»rl AffVNiTit 

VCUUC ii Will OvlvtlCU rTL^/VVJttlll. 

• Changing Account name will update 
the Account number and vice versa. 

• When "Theft" is selected, Theft 
Waiver Days (3.14) is no longer a 
required field. 

• If a value other than (Blank) is selected 
for Theft Waiver Days (3.14), the Date 
of Loss (3.12) field is then required. 

Chris Carr 

08/20/2001 

1.6 

Renamed document to Vehicle/Shop. 

Chris Can- 

08/24/2001 

1.7 

Added Country code to Not on File. 

Chris Carr 

08/30/2001 

1.8 

• Added screen shots for the United 
Kingdom, Ireland and Germany 
versions. 

• Added screen shot for Germany's 
Schwakeliste. 

• Made changes to the order of text 
descriptions of the fields to reflect the 
new order presented in the screen shots 
of the Vehicle/Shop screen. 

• License Plate Number will no longer 
be displayed for North America. 

• License Plate Number will be 
displayed as Registration Number for 
all of the European countries. 

• Removed the requirement of Date of 
Loss if a Theft Waiver Days value is 
selected. 

Chris Carr 


Confidential 


©Enterprise Rent-A-Car, 
2001 


Page 2 


Rental Redesign 

Version: 2.7 

Screen Action Specification 

Date: 12/21/2001 

Vehicle / Shop 




• Removed the "and/or" requirement for 
Contact Last Name and Contact First 
Name. Only the Last Name is now 
required. 

• Added a new section for the text 
description of the Schwakeliste fields. 


09/04/200 1 

1.9 

• Year will not be displayed ior ireianu. 

• Schwakeliste pop-up is no longer 
requircu. 

• System note needs to be generated for 
registration number and class. 

unris L<arr 

09/06/2001 

2.0 

Put in changes for Class now being a drop 
down selection field. 

Chris Carr 

Art /AZ" WAA 1 

09/06/2001 

2.1 

updated witn cnanges rrom Keservauon 

Torn A ft aKatt\/ 
JoHlCS iXXXwCTiy 

09/12/2001 

2.2 

Updated witn new screen snots containing 
new navigation areas. 

v^nris v^arr 

09/21/2001 

2.3 

• Expanded sys-gen note for Vehicle 
Year/Make/Model changed to 3 
separate notes. 

• Reinstated the "and/or" requirement 
for Contact Last Name and First Name. 

Chris Carr 

_* 

10/12/2001 

2.4 

Updated with new screen shots. 

Chris Carr 

10/23/2001 

2.5 

• Updated with new screen shots and 
verbiage that reflect the change of the 
"Add Contact" button to now say 
"New Contact". 

• Changed system notes for "Not on 
File" to reflect what was developed. 

Chris Carr 

10/30/2001 

2.6 

Added verbiage stating that blanking out 
tne Account name/numDer win men cause 
the Account number/name and Contact to 
also be blanked out. 

Chris Can- 

11/13/2001 

2.7 

• Changed theft waiver days from "One 
Day", "Two Days", "Three Days" to 
"1 Day", "2 Days" and "3 Days". 

• Added system generated notes for 
Other Make and Other Model. 

Chris Carr 


Confidential 


©Enterprise Rent-A-Car, 
2001 


Page 3 


Rental Redesign 

Version: 2.7 

Screen Action Specification 

Date: 12/21/2001 

Vehicle / Shop 


Table of Contents 

L Introduction - 6 

2. Screen Prints 6 

3. Vehicle / Shop (Figure 1, Figure 2, Figure 3) 1 1 

3.1 Registration Number (Vehicle area of Renter's Vehicle sub-screen) 1 1 

3 .2 Year (Vehicle area of Renter's Vehicle sub-screen) 11 

3 .3 Class (Vehicle area of Renter's Vehicle sub-screen) 11 

3 .4 Make (Vehicle area of Renter's Vehicle sub-screen) 1 2 

3.5 Other Make (Vehicle area of Renter's Vehicle sub-screen) 12 

3 .6 Model (Vehicle area of Renter's Vehicle sub-screen) 12 

3.7 Other Model (Vehicle area of Renter's Vehicle sub-screen) 13 

3 .8 Color (Vehicle area of Renter's Vehicle sub-screen) 13 

3.9 Other Color (Vehicle area of Renter's Vehicle sub-screen) 13 

3.10 Is Car Drivable? (Loss Information area of Renter's Vehicle sub-screen) 14 

3.1 1 Type of Loss? (Loss Information area of Renter's Vehicle sub-screen) 14 

3.12 Total Loss? (Loss Information area of Renter's Vehicle sub-screen) 14 

3.13 Date of Loss (Loss Information area of Renter's Vehicle sub-screen) 15 

3.14 Calendar button (Loss Information area of Renter' s Vehicle sub-screen) „ 15 

3.15 Theft Waiver Days (Loss Information area of Renter's Vehicle sub-screen) 15 

3.16 Vehicle Notes (Renter's Vehicle sub-screen) 16 

3.17 Account Name (Shop sub-screen) 16 

3.18 Down arrow button (Shop sub-screen) 16 

3.19 Account Number (Shop sub-screen) 17 

3 20 Search button (Shop sub-screen) * ? 

3 .2 1 Not on File button (Shop sub-screen) 18 

3 .22 Contact Name (Shop sub-screen) 18 

3.23 Down arrow button (Shop sub-screen) 19 

3 24 New Contact button (Shop sub-screen) * 9 

3.25 Phone Number (Shop sub-screen) • 19 

3 .26 Button Line Area 20 

4. Not on File (Figure 4) 20 

4.1 Name 20 

4.2 Address . 21 

4.3 Zip 21 

4.4 Geographic Framework button (lightening bolt graphic) 21 

4.5 Country 21 

4.6 City 22 

4.7 State 22 

4.8 Phone 22 

4.9 Contact Last Name 23 

4. 10 Contact First Name 23 

4.1 1 Button Line Area - Add Account Not on File - 23 

5. New Contact (Figure 5) 24 

5.1 Last Name 24 

5.2 FirstName 24 

Confidential ©Enterprise Rent-A-Car, Page 4 

2001 


Rental Redesign 

Version: 2.7 

Screen Action Specification 

Date: 12/21/2001 

Vehicle / Shop 


53 Button Line Area - Add Contact 


6. Rules 

6.1 Year, Make and Model domain values come from the database 

62 A Contact must be selected for every Account that is selected as a Shop. ... 

6.3 The system should not search for or display any deactivated Accounts 

6.4 User needs to have ability to cancel a search at any time during the search. 

6.5 Notes should be generated when any of the following events occur: 

7. Security 
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25 
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Screen Action Specification 

1 . Introduction 

This document will describe the behavioral characteristics associated with the Vehicle / Shop screen. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 


2. Screen Prints 
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Figure 1 - Vehicle / Shop (North America) 
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'2 Vehicle / Shop - Ireland and United Kingdom - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 
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Figure 2 - Vehicle / Shop (Ireland & United Kingdom) 


Confidential 


©Enterprise Rent-A-Car, 
2001 


Page 7 


Rental Redesign 

Version: 2,7 

Screen Action Specification 

Date: 12/21/2001 

Vehicle / Shop 


'3 Vehicle / Shop - Germany - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 
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Figure 3 - Vehicle / Shop (Germany) 
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'3 Vehicle / Shop - Germany - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 
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Figure 4 - Add Account Not on File 
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Figure 5 - New Contact 
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3. Vehicle / Shop (Figure 1, Figure 2, Figure 3) 

3.1 Registration Number (Vehicle area of Renter's Vehicle sub-screen) 

3.1.1 Behavior 

This is a text field in which the user may enter a Registration Number. This field only 
appears on the European versions (Figure 2, Figure 3) of the application and is hidden on 
the North American version (Figure 1). 

3.12 Validation 

No validation is necessary. 

3.1.3 Business Exceptions 

None have been identified at this time. 

3. 1.4 System Exceptions 

None have been identified at this time. 

3.2 Year (Vehicle area of Renter's Vehicle sub-screen) 

3.2.1 Behavior 

This is a drop-down field containing the Years available for searching. This field is 
hidden on the Ireland and United Kingdom version (Figure 2) of ^application and is 
visible on the North American and German versions (Figure 1, Figure 3). 

3.2.2 Validation 

No validation is necessary. 

3.2.3 Business Exceptions 

None have been identified at this time. 

3. 2. 4 System Exceptions 

None have been identified at this time. 

3.3 Class (Vehicle area of Renter's Vehicle sub-screen) 

3.3.1 Behavior 

This is a drop-down field containing a list of numbers from 1 to 10 for the User to select as the Class. 
This field only appears on the German version (Figure 3) of the application and is hidden on the North 
American and the Ireland and United Kingdom versions (Figure 1, Figure 2). 

3.3.2 Validation 

No validation is necessary. 

3.3.3 Business Exceptions 

None have been identified at this time. 

3.3.4 System Exceptions 

None have been identified at this time. 


Confidential 


©Enterprise Rent-A-Car 5 
2001 


Page 11 


Rental Redesign 

Version: 2.7 

Screen Action Specification 

Date: 12/21/2001 

Vehicle / Shop 


3.4 Make (Vehicle area of Renter's Vehicle sub-screen) 

3.4.1 Behavior 

This is a drop-down field containing a list of makes available for the Year (32) selected. 
If a Make different from "Other Make" is selected from the list, the Other Make (3.5) 
field should be cleared out. This field appears on all versions (Figure 1, Figure 2, Figure 
3) of the application. 

3.4.2 Validation 

No validation is necessary. 

3. 4. 3 Business Exceptions 

None have been identified at this time. 

3.4. 4 System Exceptions 

None have been identified at this time. 

3.5 Other Make (Vehicle area of Renter's Vehicle sub-screen) 

3.5.1 Behavior 

This is a text field in which the user may enter a Make that was not available in the drop- 
down. If a value is entered, the Make (3 .4) drop-down field should be cleared out if it has 
a value different from "Other Make". This field appears on all versions (Figure 1, Figure 
2, Figure 3) of the application. 

3.5.2 Validation 

No validation is necessary. 

3. 5. 3 Business Exceptions 

None have been identified at this time. 

3. 5. 4 System Exceptions 

None have been identified at this time. 

3.6 Model (Vehicle area of Renter's Vehicle sub-screen) 

3.6.1 Behavior 

This is a drop-down field containing a list of models available for the Make (3.4) 
selected. If a Model different from "Other Model" is selected from the list, the Other 
Model (3.7) field should be cleared out. This field appears on all versions (Figure 1, 
Figure 2, Figure 3) of the application. 

3.6.2 Validation 

No validation is necessary. 

3. 6. 3 Business Exceptions 

None have been identified at this time. 

3. 6. 4 System Exceptions 

None have been identified at this time. 
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3.7 Other Model (Vehicle area of Renter's Vehicle sub-screen) 

3.7.1 Behavior 

This is a text field in which the user may enter a Model that was not available in the drop- 
down. If a value is entered, the Model (3.6) drop-down field should be cleared out if it 
has a value different from "Other Model". This field appears on all versions (Figure 1, 
Figure 2, Figure 3) of the application. 

3.7.2 Validation 

No validation is necessary. 

3. 7. 3 Business Exceptions 

None have been identified at this time. 

3. 7. 4 System Exceptions 

None have been identified at this time. 

3.8 Color (Vehicle area of Renter's Vehicle sub-screen) 

3.8.1 Behavior 

This is a drop-down field containing a list of available colors. If a Color different from 
"Other Color" is selected from the list, the Other Color (3.9) field should be cleared out. 
This field appears on all versions (Figure 1, Figure 2, Figure 3) of the application. 

3.8.2 Validation 

No validation is necessary. 

3. 8. 3 Business Exceptions 

None have been identified at this time. 

3.8.4 System Exceptions 

None have been identified at this time. 

3.9 Other Color (Vehicle area of Renter's Vehicle sub-screen) 

3.9.1 Behavior 

This is a text field in which the user may enter a Color that was not available in the drop- 
down. If a value is entered, the Color (3.8) drop-down field should be cleared out if it has 
a value different from "Other Color". This field appears on all versions (Figure 1 , Figure 
2, Figure 3) of the application. 

3.9.2 Validation 

No validation is necessary. 

3. 9. 3 Business Exceptions 

None have been identified at this time. 

3. 9. 4 System Exceptions 

None have been identified at this time. 
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3.10 Is Car Drivable? (Loss Information area of Renter's Vehicle sub-screen) 

3.10.1 Behavior 

This is a drop down field containing the following domain values: 

• (Blank) - Default 

• Yes 

• No 

This field appears on all versions (Figure 1, Figure 2, Figure 3) of the application. 

3.10.2 Validation 
No validation is necessary. 

3.10.3 Business Exceptions 
None have been identified at this time. 

3.10.4 System Exceptions 
None have been identified at this time. 

3.1 1 Type of Loss? (Loss Information area of Renter's Vehicle sub-screen) 

3.11.1 Behavior 

□ This is a drop down field containing the following domain values: 

H • (Blank) - Default * 

W • Damage 

• Theft 

This field appears on all versions (Figure 1, Figure 2, Figure 3) of the application. 

3.11.2 Validation 

01 No validation is necessary. 

3.11.3 Business Exceptions 
None have been identified at this time. 

3.114 System Exceptions 

None have been identified at this time. 

3.12 Total Loss? (Loss Information area of Renter's Vehicle sub-screen) 

3. 12. 1 Behavior 

This is a drop down field containing the following domain values: 

• (Blank) - Default 

• Yes 

• No 

This field appears on all versions (Figure 1, Figure 2, Figure 3) of the application. 

3.12.2 Validation 
No validation is necessary. 

3.12.3 Business Exceptions 
None have been identified at this time. 


s .. 
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3.12.4 System Exceptions 

None have been identified at this time. 

3.13 Date of Loss (Loss Information area of Renter's Vehicle sub-screen) 

3.13.1 Behavior 

This is a text field in which the user may enter a date value. This field appears on all 
versions (Figure 1, Figure 2, Figure 3) of the application. 

3.13.2 Validation 

Entered data should be in a MM/DD/YYYY format. 

3.13.3 Business Exceptions 

None have been identified at this time. 

3.1 3 A System Exceptions 

None have been identified at this time. 

3.14 Calendar button (Loss Information area of Renter's Vehicle sub-screen) 

3.14.1 Behavior 

This will bring up a calendar pop-up window allowing the user to select a specific date. 
The selected date will fill the Date of Loss (3.13) field. This button appears on all 
versions (Figure 1, Figure 2, Figure 3) of the application. 

3.14.2 Validation 

No validation is necessary. 

3.14.3 Business Exceptions 

None have been identified at this time. 

3. 14. 4 System Exceptions 

None have been identified at this time. 

3.15 Theft Waiver Days (Loss Information area of Renter's Vehicle sub-screen) 

3.15.1 Behavior 

This is a drop down field containing the following domain values: 

• (Blank) - Default 

• IDay 

• 2 Days 

• 3 Days 

This field only appears on the North American version (Figure 1) of the application and is hidden on the 
European versions (Figure 2, Figure 3). 

3.15.2 Validation 

No validation is necessary. 

3.15.3 Business Exceptions 

None have been identified at this time. 
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3.15.4 System Exceptions 

None have been identified at this time. 

3.1 6 Vehicle Notes (Renter's Vehicle sub-screen) 

3.16.1 Behavior 

This is a free form text field in which the user may enter data. The information entered 
here is only visible from this screen. This field appears on all versions (Figure 1, Figure 
2, Figure 3) of the application. 

3.16.2 Validation 

No validation is necessary. 

3.16.3 Business Exceptions 

None have been identified at this time. 

3.16.4 System Exceptions 

None have been identified at this time. 

3.17 Account Name (Shop sub-screen) 

3.17.1 Behavior 

This field's value is entered when: * 

• User enters the Account name. 

• User clicks the "down arrow" button (3.18) to the immediate right and selects an 
Account from the Branch Short list. 

• User enters a valid number in the Account Number (3.19) field. That number' s 
Account name value will then populate this field. 

• User clicks the "Search" button (3.20) and selects an Account from the Account 
Information list. 

• User clicks the "Not on File" button (3.21) and enters the appropriate new 
Account information. 

If an Account name is entered, the Account Number (3.19), Contact Name (3.22) and Phone Number (3.25) 
fields will then be populated. If the Account name is blanked out and the user tabs off or leaves the field, 
Account Number (3.19) and Contact (3.22) will also be blanked out. This field appears on all versions 
(Figure 1, Figure 2, Figure 3) of the application. 

3.17.2 Validation 

No validation is necessary. 

3.17.3 Business Exceptions 

None have been identified at this time. 

3.17 A System Exceptions 

None have been identified at this time. 

3.18 Down arrow button (Shop sub-screen) 

3.18.1 Behavior 

This will bring up the Branch Short list allowing the user to select a specific Account. If 
in Europe, the European Branch Short list will be brought up. If an Account is selected, 
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the Account Name (3.17), Account Number (3.19), Contact Name (3.22) and Phone 
Number (3.25) fields will then be populated. This button appears on all versions (Figure 
1, Figure 2, Figure 3) of the application. 

3.18.2 Validation 

No validation is necessary. 

3.18.3 Business Exceptions 

None have been identified at this time. 

3.1 8 A System Exceptions 

None have been identified at this time. 

3.19 Account Number (Shop sub-screen) 

3.19.1 Behavior 

This field's value is entered when: 

• User enters a valid name in the Account Name (3.17) field. That name's Account 
number value will then populate this field. 

• User clicks the "down arrow" button (3.18) to the immediate left and selects an 
Account from the Branch Short list. 

• User enters the Account number. $ 

• User clicks the "Search" button (3.20) and selects an Account from the Account 
Information list. 

• User clicks the "Not on File" button (3.21) and enters the appropriate new 
Account information. 

If an Account number is entered, the Account Name (3.17), Contact Name (3.22) and Phone Number (3.25) 
fields will then be populated. If the Account number is blanked out and the user tabs off or leaves the field, 
Account Name (3.17) and Contact (3 .22) will also be blanked out. This field appears on all versions (Figure 
1 , Figure 2, Figure 3) of the application. 

3.19.2 Validation 

No validation is necessary. 

3.19.3 Business Exceptions 

None have been identified at this time. 

3.19.4 System Exceptions 

None have been identified at this time. 

3.20 Search button (Shop sub-screen) 

3.20.1 Behavior 

This will bring up the Account Search screen allowing the user to search for and then 
select a specific Account. If an Account is selected, the Account Name (3.17), Account 
Number (3.19), Contact Name (3.22) and Phone Number (3.25) fields will then be 
populated. This button appears on all versions (Figure 1, Figure 2, Figure 3) of the 
application. 
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3.20.2 Validation 

No validation is necessary. 

3.20.3 Business Exceptions 

None have been identified at this time. 

3. 20. 4 System Exceptions 

None have been identified at this time. 

3.21 Not on File button (Shop sub-screen) 

3.21 1 Behavior 

This will bring up the Add Account Not on File screen (Figure 4) allowing the user to 
enter information for a new Account. After all the necessary fields on that screen are 
entered, the Account Name (3.17), Account Number (3.19), Contact Name (3.22) and 
Phone Number (3.25) fields will then be populated with that screen's entered 
information. This button appears on all versions (Figure 1, Figure 2, Figure 3) of the 
application. 

3.212 Validation 

No validation is necessary. 

3213 Business Exceptions 

None have been identified at this time. 

3.214 System Exceptions 

None have been identified at this time. 

3.22 Contact Name (Shop sub-screen) 

3.22.1 Behavior 

This field's value is entered when: 

• User enters a valid name in the Account Name (3.17) field. That name's Contact 
name value will then populate this field. 

• User clicks the "down arrow" button (3.18) to the immediate right of Account 
Name (3.17) and selects an Account from the Branch Short list. That Account's 
Contact name value will then populate this field's value. 

• User enters a valid number in the Account Number (3.19) field. That number' s 
Contact name value will then populate this field. 

• User clicks the "Search" button (3.20) and selects an Account from the Account 
Information list. That Account's Contact name value will then populate this 
field's value. 

• User clicks the "Not on File" button (3 .2 1) and enters the appropriate new Contact 
information after the new Account information. After all the necessary fields on 
that screen are entered, that screen's entered information for Contact name will 
then populate this field's value. 

• User enters the Contact name. 

• User clicks the "down arrow" button (3.23) to the immediate right and selects a 
Contact from the Contact list. 
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• User clicks the "Add New" button (3 .24) and enters the appropriate new Contact 
information. 

This field appears on all versions (Figure 1, Figure 2, Figure 3) of the application. 

3.22.2 Validation 

No validation is necessary. 

3.22.3 Business Exceptions 

None have been identified at this time. 

3.22.4 System Exceptions 

None have been identified at this time. 

3.23 Down arrow button (Shop sub-screen) 

3.23.1 Behavior 

This will bring up the Contact list allowing the user to select a specific Contact. If a 
Contact is selected, the Contact Name (3.22) field will then be populated. This button 
appears on all versions (Figure 1 5 Figure 2, Figure 3) of the application. 

3.23.2 Validation 

No validation is necessary. 

s 

3.23.3 Business Exceptions 

None have been identified at this time. 

3. 23. 4 System Exceptions 

None have been identified at this time. 

3.24 New Contact button (Shop sub-screen) 

3.24.7 Behavior 

This will bring up the New Contact screen (Figure 5) allowing the user to enter 
information for a new Contact 

After the necessary field(s) on that screen is/are entered, the Contact Name (3.22) field 
will then be populated with that screen's entered information. This button appears on all 
versions (Figure 1, Figure 2, Figure 3) of the application. 

3.24.2 Validation 

No validation is necessary. 

3.24.3 Business Exceptions 

None have been identified at this time. 

3.24.4 System Exceptions 

None have been identified at this time. 

3.25 Phone Number (Shop sub-screen) 

3.25.1 Behavior 

This field's value is entered when: 
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• User enters a valid name in the Account Name (3.17) field. That name's Phone 
number value will then populate this field. 

• User clicks the "down arrow" button (3.18) to the immediate right of Account 
Name (3.17) and selects an Account from the Branch Short list. That Account's 
Phone number value will then populate this field's value. 

• User enters a valid number in the Account Number (3.19) field. That number's 
Phone number value will then populate this field. 

• User clicks the "Search" button (3.20) and selects an Account from the Account 
Information list. That Account's Phone number value will then populate this 
field's value. 

• User clicks the "Not on File" button (3.21) and enters the appropriate new 
Account information. That Account's Phone number value will then populate this 
field's value. 

• User enters the Phone number. 

This button appears on all versions (Figure 1, Figure 2, Figure 3) of the application. 

3.25.2 Validation 

No validation is necessary. 

3.25.3 Business Exceptions 

None have been identified at this time. 

3. 25. 4 System Exceptions 

None have been identified at this time. 

3.26 Button Line Area 

3.26.1 Behavior 

The Previous button will take the user to the Bill-to screen within the same transaction. 

The Next button will take the user to the Notes screen within the same transaction. 

The Complete button will initiate a save of the transaction. All validations will be 
performed, returning any errors to the user. If there are no errors, the transaction is 
saved, and the user is returned to the Open Ticket home page. 

4. Not on File (Figure 4) 
4.1 Name 

4.1.1 Behavior 

This is a text field in which the user may enter an Account name. 
4.12 Validation 

No validation is necessary. 

4. 1. 3 Business Exceptions 

None have been identified at this time. 
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4. 1 4 System Exceptions 

None have been identified at this time. 

4.2 Address 

4.2.1 Behavior 

This is a free form text field in which the user may enter an Account's address. 

4.2.2 Validation 

No validation is necessary. 

4. 2. 3 Business Exceptions 

None have been identified at this time. 

4. 2. 4 System Exceptions 

None have been identified at this time. 

4.3 Zip 

4.3.1 Behavior 

This is a text field in which the user may enter an Account's zip code. 

4.3.2 Validation 

No validation is necessary. * 

4. 3. 3 Business Exceptions 

None have been identified at this time. 

4. 3. 4 System Exceptions 

None have been identified at this time. 

4.4 Geographic Framework button (lightening bolt graphic) 

4.4. 1 Behavior 

This will fill in the City (4.6) and State (4.7) fields if there is only 1 city for the zip code. 
If more than 1 city is in the entered zip code, the Multiple Cities Found page will be 
brought up, allowing the user to select a city. The City (4.6) and State (4.7) fields will 
then be filled with the user's selection. 

4.4.2 Validation 

No validation is necessary. 

4. 4. 3 Business Exceptions 

None have been identified at this time. 

4.4.4 System Exceptions 

None have been identified at this time. 

4.5 Country 

4.5.1 Behavior 

This is a drop down field containing the list of countries. 
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4.5.2 Validation 

No validation is necessary. 

4. 5. 3 Business Exceptions 

None have been identified at this time. 

4. 5. 4 System Exceptions 

None have been identified at this time. 

4.6 City 

4.6.1 Behavior 

This is a text field in which the user may enter an Account's city. This field may also be 
filled by actions performed by the Geographic Framework button (4.4). 

4.6.2 Validation 

No validation is necessary. 

4. 6. 3 Business Exceptions 

None have been identified at this time. 

4. 6. 4 System Exceptions 

None have been identified at this time. * 

4.7 State 

4.7.1 Behavior 

This is a drop down field containing the list of states. This field may also be filled by 
actions performed by the Geographic Framework button (4.4). 

4.7.2 Validation 

No validation is necessary. 

4. 7.3 Business Exceptions 

None have been identified at this time. 

4. 7. 4 System Exceptions 

None have been identified at this time. 

4.8 Phone 

4.8.1 Behavior 

This is a text field in which the user may enter an Account's phone number. 

4.8.2 Validation 

Entered data should be 10 digits for the US to include area code or the appropriate format 
for other countries. 

4. 8. 3 Business Exceptions 

None have been identified at this time. 

4. 8. 4 System Exceptions 

None have been identified at this time. 
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4.9 Contact Last Name 

4.9.1 Behavior 

This is a text field in which the user may enter a Contact's last name for the new 
Account. 

4.9.2 Validation 

No validation is necessary. 

4. 9. 3 Business Exceptions 

None have been identified at this time. 

4. 9. 4 System Exceptions 

None have been identified at this time. 

4.1 0 Contact First Name 

4.10.1 Behavior 

This is a text field in which the user may enter a Contact's first name for the new 
Account. 

4.10.2 Validation 

No validation is necessary. t 

4.10.3 Business Exceptions 

None have been identified at this time. 
4.1 OA System Exceptions 

None have been identified at this time. 

4.11 Button Line Area - Add Account Not on File 

4.11.1 OK button 

4.11.1.1 Behavior 

If data is not present in the required fields the feedback message explains that a value 
needs to be entered in the field(s) that is/are blank. Two options are presented, OK and 
Cancel. OK takes the user back to the Add Account Not on File screen for data entry; 
Cancel dismisses the Add Account Not on File screen. 
OK will be the default selection. 

4.11.1.2 Validation 

There must be data present in all fields except for Contact Last Name (4.9) and First 
Name (4.10) where only one needs to have data present. 

4.11.1.3 Business Exceptions 

None have been identified at this time. 

4. 1 1 . 14 System Exceptions 

None have been identified at this time. 
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4.11.2 Cancel button 

4.11.2.1 Behavior 

This button will dismiss the Add Account Not on File screen without saving any data. 

4.11.2.2 Validation 

If data has been entered the following feedback message is displayed; "Are you sure you 
want to exit and lose the entered information?" Two options are presented, Yes and No. 
Yes will dismiss the screen and not save the data, No will take the user back to the Add 
Account Not on File screen. 
The default button selection is "No". 

4. 1 1 .2.3 Business Exceptions 

None have been identified at this time. 

4.11.2.4 System Exceptions 

None have been identified at this time. 

5. New Contact (Figure 5) 

5.1 Last Name 

5. 1 1 Behavior 

This is a text field in which the user may enter a Contact's last name for an already 
selected Account. 

5.12 Validation 

No validation is necessary. 

5. 1. 3 Business Exceptions 

None have been identified at this time. 

5. 1. 4 System Exceptions 

None have been identified at this time. 

5.2 First Name 

5.2.1 Behavior 

This is a text field in which the user may enter a Contact's first name for an already 
selected Account. 

5.2.2 Validation 

No validation is necessary. 

5. 2. 3 Business Exceptions 

None have been identified at this time. 

5. 2. 4 System Exceptions 

None have been identified at this time. 
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5.3 Button Line Area - Add Contact 

5.3.1 OK button 

5.3.1.1 Behavior 

If data is not present in the Last Name (5.1) and/or the First Name (5.2) field(s), the 
feedback message explains that a value needs to be entered for Last Name (5.1) and/or 
First Name (5.2). Two options are presented, OK and Cancel OK takes the user back to 
the Add Contact screen for data entry, Cancel dismisses the Add Contact screen. 
OK will be the default selection. 

5.3.1.2 Validation 

There must be data present in the Last Name (5.1) and/or First Name (5.2) field(s). 

5.3.1.3 Business Exceptions 

None have been identified at this time. 

5.3.1.4 System Exceptions 

None have been identified at this time. 

5.3.2 Cancel button 

5.3.2.1 Behavior 

This button will dismiss the Add Contact screen without saving any data. 

5.3.2.2 Validation 

If data has been entered the following feedback message is displayed; "Are you sure you 
want to exit and lose the entered information?" Two options are presented, Yes and No. 
Yes will dismiss the screen and not save the data, No will take the user back to the Add 
Contact screen. 

The default button selection is "No" 

5.3.2.3 Business Exceptions 

None have been identified at this time. 

5.3.2.4 System Exceptions 

None have been identified at this time. 

6. Rules 

6.1 Year, Make and Model domain values come from the database. 

6.2 A Contact must be selected for every Account that is selected as a Shop. 

6.3 The system should not search for or display any deactivated Accounts. 

6.4 User needs to have ability to cancel a search at any time during the search. 
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6.5 Notes should be generated when any of the following events occur: 


"Not on File" 
Shop 

oiiup i^DiaiUvj Was CXlcUlgCu lO 

"XXXX" 

creai 
e/Edit 

create jii aata exists 
from the reservation) 
/Edit 

venicie/on 
op 

T I^pr aHfta 3 

KJ Owl GUU3 a 

"Not on File" 
Shop Contact 

1NUL Ull rilC v^UXllav'l FiToL iNdHlC JL»aSl 

Name" was added for Account 
"XXXXX" 

creai 
e/Edit 

create (n aaia exisxs 
from the reservation) 
/Edit 

venicie/on 
op 

the Shop 
Account 

oiiup A-A-Ayv was cnangeu to 
"XXXX" 

E/Glt 

create (ii aata exists 
from the reservation) 
/Edit 

venicie/oxi 
op 

T To At* /^riot^rroc 1 

user uxiangeb 
the Type of 
Loss 

l ype oi loss aaaa was cnangea 
to "XXXX" 

Jbult 

create (it data exists 
from the reservation) 
/Edit 

Venicle/an 
op 

User changes 

the* "T7\to1 

me i otai 

Loss?" 

Total Loss "XXXX" was changed to 

«"VW"V" 

AAAA . 

Edit 

Create (if data exists 
from the reservation) 
/Edit 

Vehicle/Sh 
op 

User changes 
the Date of 

LOSS 

Date of Loss "XXXXXX" was 
changed to "XXXXXX" 

Edit 

Create (if data exists 
from the reservation) 

ATI-' 1 *j_ 

fEdit 

Vehicle/Sh 
op 

User changes 
number of 
inert waiver 
Days 

Theft Waiver Days "X" was changed 
to "X" 

Edit 

Create (if data exists 
from the reservation) 

/halt 

Vehicle/Sh 
op (North 
America) 

User changes 

trie 
Registration 
Number 

Registration Number "XXXX" was 
changed to XXXX 

Edit 

Edit 

Vehicle/Sh 

/T 1 J 

op (Ireland, 

UK, 
Germany) 

User changes 
tne Class 

Class "XX" was changed to "XX" 

Edit 

Edit 

Vehicle/Sh 
op 

(Germany) 

User changes 
the Renter's 
Vehicle s Year 

The Renter's Vehicle Year "XXXX" 
was changed to Year "XXXX" 

Edit 

Edit 

Vehicle/Sh 
op 

User changes 
the Renter's 
Vehicle's 
Make 

The Renter's Vehicle Make "XXXX" 
was changed to Make "XXXX" 

Edit 

Edit 

Vehicle/Sh 
op 

User changes 
the Renter's 
Vehicle's 
Model 

The Renter's Vehicle Model 
"XXXX" was changed to Model 
"XXXX" 

Edit 

Edit 

Vehicle/Sh 
op 

User changes 
the Renter's 
Vehicle Other 

The Renter's Vehicle Other Make 
"XXXX" was changed to "XXXX" 
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Edit 

bar, 

Edit 

P 

Vehicle/Sh 
op 

age 26 

User changes 
the Renter's 
Vehicle Other 

The Renter's Vehicle Other^flel 
"XXXX" was changed to "XXXX" 

Edit 

Edit 

Vehicle/Sh 
op 
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7. Security 

A user is authorized through a login process to create or edit a reservation or ticket 
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Screen Action Specification 


1. Introduction 


2. 

2.1 


This document will describe the behavioral characteristics associated with the Bill to screen used in 
Reservation and Open. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 

Screen Prints 
Main Screen 


- 3 Enterprise* ECA RS Application - Microsoft Internet Eicplorer provided by Enterprise Rent-a-Car 


DRIVERS 


I SD VOID SDSDSD 


Bill-To 


[-Options- 


REFERRAL 


DATES/ RATES 


r Bill-To 

Account Name: 

jtestNmae 


Account Number: 
[999999 ~ 


Contact Name: 
[conlnam confnam j ^ 


Phone Number: 


5612561565 



testNmae 
conlnam confnam 


VEHICLE/SHOP 


NOTES 


Notes Taken : 5 


[-Vehicle Authorization- 
Start Date 


Start Time 


End Date 


End Time 


Daily Amount 


r 


_j 


Tax 


Authorized By 
[-Select- 


Status 


Green-screen ECARS Auth Amount: 
Claim Type Insured Name Claim/Po!/PO/RO 


r Maximum Information— _ 

Max Per Day Total Max Amount Max # Days Last Day 


r. 


,\\V. 

\ ; 


Res - 1216FC 


Res - 1216FD 
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2.2 Account Search 


t Search - 



Account Search 


Group: 


1 01 jSU-Qiife_ 



Account Name 


Account Phone Number 


Account Type 


A Collector's Bookstore** 


GE1658 Corporate 0101 6275 Delmar 


A.f.i. Remodelino Co** 


St. Louis MO 63130 (314)721- 

6127 


Accenr Lincoln-mercury** 


QE1225 Corporate 0102 312 Oak Pk. Village Dr, Wildwood MO 63040 636 458-1552 77 


129498 Dealership 0103 9700 Manchester Rd 


Advantage Decorating** 


St Louis MO 63 119 (314)968- 

5300 


GE0353 Corporate 0104 1601 North 7th St. 


African Amer. Rite Of Pass**!*** GE1538 Corporate Q1Q5 325 Debaliviere 


St. Louis MO 63102 (314)436- 

1419 


Ahead Boqostan** 


6E0830 Corporate 0106 7743 Arthur 


St. Louis MO 63112 314 3612268 ] V 

St Louis MO 63117 (314) 645- 

3076 


Aiq-cs** 


GE0238 Corporate 0107 120 S Central, Ste 300 St Louis » MO 63105 (000)000- 
0000 


I Al-pac, Inc.** 


6E1350 Corporate 0108 18535 Old Hwy 66 


Pacific MO 63069 (636)271-8222 . 5 - 


Albertin Auto &ody Inc** 


G03868 Bodyshop 01 09 8449 Page 


.??L0U!? MO 63130_ (314)423- V| 


Items 1 - 66 of 66 found 


Prev 12 3 4 5 Next 
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2.3 Not on File 


Not on File 


Name: 


Address: 


Zip: 


Phone: 


l: 

City: 



State: 


Contact Last Name: 


c 


Contact First Name: 



Last Saved: 
26 October 2001 8:53 AM 


{ 


2.4 Add Contact 


Add Contact 


Last Name: 


First Name: 


— i 
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2.5 Rates Table 



3. 

3.1 


3.2 


Reservation Number 

SUPLpendina1.Dendina2 Behavior 

This area shows the unique reservation number that has been assigned to the newlv created reservation. 
The reservation number is 6 alphan umeric ch aracters long. If another reservation is open, its reservation 
will be displayed in this area as well. The user will have the ability to have up to 3 reservations open at a 
time. A hyperlink will be available on the reservation numbers of the reservations that are NOT currently 
For the reservation t hat is currently displayed, t he reservation number will not have a 


hyperlink available. This is to allow the user to ns 
Validation 

None identified at this time. 


ithe open reservations. 


3.3 SUPLpendingl.pendin aS Busine ss Exceptions 

If the user tries to open a 4 th reservation, the system will display a mes 
reservations m av be displayed." 

3.4 System Exceptions 

None identified at this time. 

4, Bill-to Title Bar Area 

4.1 Behavior 

The o ption area in the bill-to Title Bar will allow the user to access transaction-wide functions. These 
functions for Reservation are: - Options — . Print. Void and Transfer. The default option is " — O ptions - 
*L The user must press thejGo button to initiate the selected function. 

The Title bar Button area contains two buttons - a Go button an d a Close button. 

The Go button § always active, and is used to initiate a function selected in the Options area. !£&£ 
selected option is "—Optio ns (the default), nothing should happen. 

The Close button is always active and is used to close the current transaction. The button is labeled with an 
*X». Pressing this button will cause a confirmation popup to appear, asking the user if thev wish to cancel 
the transaction and lose all changes. If the user s elects 'No', thev are r eturned to the Bill-to screen. If the 
res', the transaction is closed with no change? saved to the database. 
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4.2 Validation 

None identified at this time. 

4.3 Business Exceptions 

None identified at this time. 

4.4 System Exceptions 

None identified at this time. 


5. Button Line Area 

5.1 Behavior 

The Previous button will ta ke the user to the Dates/Rates screen within the same transaction. 
The Next butto n will take th e user to the Vehicle/Sho p screen within the same t ransaction. 


The Cc 


%ve of the transaction. 


/ill beperfomied,ret 


errors to the user, if there are no errors, the transaction is saved, and the user is returned to the Open 
Ticket home page. 


5.2 Validation 

None identified at this time. 

5.3 Business Exceptions * 

None identified at this time. 

5.4 System Exceptions 

None identified at this time. 

6. Bitl-to 

6.1 Account Name 

This is a drop down which displays the "branch short list" of Account Names when the user hits the button 
beside it. Or. if the user begins to type anything in the field, a drop down will automatically appear and 
continue to posi tion to the name most closely matching what has been typed. 

Drop down. If the user selects an account not authorized to bill f "Source onlv"> then the system presents 
message and user can make another selection or clear the field and use "Not on File." 

6. 1. 1 Business Exceptions 
None. 

6.1.2 System Exceptions 
None. 

6.2 Account Number 

Tf the user has se lected a na me from the d rop-down, the correspon ding number s hould appear here. 

Alternatively, the user can enter an Account number in this field. 

Validation of the value in the field is performed when the user selects the "Search" button. 
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If the number isn't a valid account then the system provides a messa ge. If it is vali d, but not billable, then 
the user can make anoth er selection or clear the field and use if Not on File." 

6. 2. 1 Business Exceptions 
None. 

6. 2. 2 System Exceptions 
None. 

6.3 "Search" button 

If this button is used when an account numb er is in the " Account Number" field, then it validates the 
account number. 

If not account number is present, then the "Account Search" screen is displayed. 

In the first scenario above, if the account is not valid, a message is displayed. ( See Referral Source for up- 
to-date functionality.) 

6. 3. 1 Business Exceptions 
None. 

ft 3. 2 System Exceptions 
None. 

6.4 "Not on File" Button 

Takes the user a s creen to add a bill-to. T his should also blank out th e^count name and th e Account 
number. 

Upon returning from the panel the name should be in the Account Name field and the Account Number 
should be blank 

6.4.1 Validation 
None. 

ft 4. 2 Business Exceptions 
None. 

ft 4. 3 System Exceptions 

None. 

6.5 Contact Name 

This is a drop-down based on the account name sel ected above. 

If not account name is selected, then the drop-down should be blank. 

6. 5. 1 Business Exceptions 
None. 

6. 5. 2 System Exceptions 
None. 
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6,6 "Add New" Button 

present in the drop -down. 

This pulls up a panel for the user to ente r the first an d or last name. 

6.6.1 Validation 
None. 

6. 6. 2 Business Exceptions 
None. 

6. 6.3 System Exceptions 
None. 

6-7 Phone Number 

The user may add or u pdate a number for the contact selected. This number is only saved on the contract. 
Standard phone number formatting 

6. 7. 1 Business Exceptions 
None. 

6. 7. 2 System Exceptions % 
None. 

6.8 Overall behavior 

Once an account is selected (either bv drop-down or bv entering the number manua lly, the "Bill-to X" 
hyperlink is chan ged to the nam e of the account. 

A§ a bill-to is added the ne xt "Bill-to X" is added to the list across the top, so as to allow the user to add 
another Bill-to. The maximum number of Bill-tos is four. This functionality will not be available for 
Reservation Pilot since only one hilUto is allowed. 

7. Vehicle Authorization 

7.1.1 Behavior 

The start date should default to the open dat e and time of the ticket ( either real for an o pen ticket or 
projected, in the case of a reservation! 

7.12 Validation 

Standard date formatting. 

Must be a date within the range of p ickup date and return date. 
Requires a statu s of "Authorised" 

7. 1.3 Business Exceptions 
None. 

7.1.4 System Exceptions 
None. 
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7.2 Start Date Button 


7.2.1 


)isp1avs calendar for date selection 


7.2.2 Validation 
Standard da 

7. 2. 3 Business Exceptions 
None. 

7. 2. 4 System Exceptions 
None. 

7.3 Start Time 

7.3.1 Behavior 


If the ticket or reservation is 24 billing cvcle. then the value defaults t o the d/ud time fif available! If no 
h Pickup time is available, the default value is 'blank'. 


SI 7.3.2 Validation 

02 This field is only valid for 24 hour billing, I f the ticket is cal endar dav billing, the dro p down should not 

p work. If 24h billing, then the values are 15 minute increments around the clock. 


7.3.3 Business Exceptions 
None. 


Ill 7.3 A System Exceptions 

Hi 
in 


i fa 

None. 


7.4 End Date 

7.4.1 Behavior 

The end date should default blank . 

7.4.2 Validation 

Standard date formatting . 

Must be a date which is equal to or after the Start Date. 
Requires a st atus of " Authorized" 

7. 4. 3 Business Exceptions 
None. 

7. 4.4 System Exceptions 
None. 

7.5 End Date Button 

7.5.1 Behavior 

Displays calendar for d ate selection 
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7. 5. 3 Business Exceptions 
None. 

7. 5. 4 System Exceptions 
None. 

7.6 End Time 

7.6.1 


If the ticket or reservation is 24 billing cycle, then the value defaults to the same va 

7.6.2 Validation 

Ihjs.fleld is only valid for 24 hour billing. If the ticket is calendar dav billing the drop down should not 

7. 6. 3 Business Exceptions 
None. 

7. 6. 4 System Exceptions 

None. * 


7.7 No. of Days 

7.7.1 Behavior 

If the start date and en d date are cor 
Removed for Reservation Pilot. 


ild be filled with the number of < 


7.7.2 Validation 

Valid values are 0 and any integer. 

If the user skios end date, the system will determine the date using this value in association with the start 


7. 7. 3 Business Exceptions 
None. 

7. 7 4 System Exceptions 

None. 

7.8 Daily Amoun t vs. Total Charges Toggle 

7.8.1 Behavior 

User selects one or the other. 

Iftotal charges, then leave daily amount field and tax field blank. 

If the user elects to add information in to the daily amount field or the tax field and the "Total Charges" are 


selected, tfo 


i^e the toggle to the Pail 
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7.8.2 Validation 

If daily (along with authorized status = "authorized "^, then authorized amou nt, tax and aiithorized bv are 
required. 

If total charges (along with a uthorized status = "authorized"), then authorized bv is required. 

******NOTE 4.8 will not be for Reservation Pilot The users will not have the ability to choose total 
charges, 

7. 8. 3 Business Exceptions 
None. 

7. 8. 4 System Exceptions 
None. 

7.9 Daily Amount Field 

7.9.1 Behavior 

If this field is changed bv the user, the system should ensure that the toggle for "Daily Autho rization" is 


Q selected. 

This field can be filled in bv the user, or bv the "Rate List Button' 


MUST 


i 15? 


? 7.9.2 Validation 


m 

Ms 

ru. 


Alpha numeric 

7.9.3 Business Exceptions 
None. 


7. 9. 4 System Exceptions 
m None. 


7.10 Rate List Button 

7.10.1 Behavior 

Takes the us er to a screen to nick a car class from the "Rates Table". The car class and all assoc iated rates 
for the ticket are saved in the ticket although it doesn't show on the screen. If the rate tha t is retrieved is 
tiered, then the rate from the first t ier is put in the daily amount field and the tier flag is checked. 

7.10.2 Validation 

Tf the bill-to does not have negotiated rates in the system , this button will return nothing. 

7.10.3 Business Exceptions 
None. 

7.10.4 System Exceptions 
None. 

7.11 Tier Flag 

7.11.1 Behavior 

■ ■ 

System u pdated based on the criteria listed in the Rate L ist Button behavior. 
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None. 

7.11.3 Business Exceptions 
None. 

7 A 1.4 System Exceptions 
None. 

7.12 lax 

7.12.1 Behavior 

Dro p down to indicate either "included" or "plus tax". Should definite to "included. 


Last Saved: 
26 October 2001 8:53 AM 


j«3, 

o 

fl 


MJ 


us a. 

hi 


7.12.2 Validation 

This field is required with a daily authoriz ation when the status is "authorized." 

7.12.3 Business Exceptions 
None. 

7.f2.4 System Exceptions 
None. 

7.13 Authorized Bv 

7.13.7 Behavior 

Drop down of all of the contacts for the hill-to. See Contact name. 

7.13.2 Validation 

Authorized bv is 

7.13.3 Business Exceptions 
None. 

7.13.4 System Exceptions 
None. 

7.14 "Add New" C ontact Button 

See Add New from Bill-to. 


7.15 Output field for Gre< 


=CARS Auth A mount Field 


7.15.1 Behavior 

This is an output field that displays the information frnm the Max Amount Field in the, Reservation / Open 
Ticket. 


Anytime the contract is saved, this field is u pdated with the values from the Daily Amount concatenate^ 
with the Total Max Amount and saved to legacy that wav. If both of " 
is made. 
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7.15.2 Validation 
None 

7.15.3 Business Exceptions 
None 

7 .15 A System Exceptions 
None 

7.16 Status 

7.16.1 Behavior 

lue is 'blankl 


Last Saved: 
26 October 2001 8:53 AM 


The user can select one of the following: REINBURSEMENT. AUTHORIZED. PENDING. DECLINED. 
TERMINATED. 


7.16.2 Validation 
0 If the user selects 


in the authorization information box are required. See those 


p fields for those. notes, 

03 7.16.3 Business Exceptions 


None. 


W 7.16.4 System Exceptions 


None. 


fy 


7.17 Claim Type 

01 7.17.1 Behavior 


Dro p-down. The user ca n select from among "Insi 
determined for each country.) 

Default to "blank", 


it, or Theft. 


gnt values will be 


7.17.2 Validation 


len the rent 


7. 1 7. 3 Business Exceptions 
None. 

7.17.4 System Exceptions 
None. 

7.18 Insured Name 

7.18.1 Behavior 

Ihi$ i$ a.text fie ld, 

7.18.2 Validation 
Optional. 
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The bill-to account may require that information be captured in this field (AASI02), but it is only required 
at the time of close. The account may, however, require that any information in the field be in a particular 
format. This is to be enforced during Reservation, Open and Close. 

7.18.3 Business Exceptions 
None. 

7.18.4 System Exceptions 
None. 

7.19 Claim/Pol/PO/RO 

7.19.1 Behavior 

7.19.2 Validation 
Optional. 

The bill-to account may require that information be captured in this field (AASI02), but it is only required 
5 at the time of close. The account may, however, require that any information in the field be in a particular 

format. This is to be enforced during Reservation, Open and Close. 


i W 

H 7.19.3 Business Exceptions 


•S 


iii 


None. 


7.19.4 System Exceptions 
■l None. 


8. Maximum Information 

8.1 Overall behavior 

8.2 May Per Dav 

8.2.1 Behavior 

This is a numeric field which must support the local currency formatting. 

8.2.2 Validation 

This field is not required. 

8.2.3 Business Exceptions 
None. 

8. 2. 4 System Exceptions 
None. 

8.3 Tntal May Amount 

8.3.1 Behavior 

This is a numeric field which mus t support the currency formatting. 
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8.3.2 Validation 

This field is n ot req uired. 

8.3.3 Business Exceptions 
None. 

8.3.4 System Exceptions 
None. 

8.4 Max # Days 

8.4. f Behavior 

This is a numeric field which must support integers, 

8.4.2 Validation 


U 


i«% 8.4.3 Business Exceptions 

lias? 

None. 


a IS s 


o 

hi 


8. 4. 4 System Exceptions 
None. 

8.5 Last Dav 

8.5.1 Behavior 

This is a date field. 


m 8.5.2 Validation 
O This field it 

8. 5. 3 Business Exceptions 
None. 

8. 5. 4 System Exceptions 
None. 

8.6 "Last Dav" Calendar button 

8.6.? Behavior 

Display* calendar for date selection 

8.6.2 Validation 

Standard date calendar. 

8.6.3 Business Exceptions 
None. 

8. 6. 4 System Exceptions 
None. 
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9. Other Authorizations 

9.1 Overall behavior 

This section will be omitted from Reservation Pilot. It will only be incorporated once the Perot 
system has been integrated. 

9.2 Item 

9.2.1 Behavior 

Drop-down to select from the products available at the renting branch. 

9.2.2 Validation 
None. 

9.2.3 Business Exceptions 
None. 

9. 2. 4 System Exceptions 
None. 

9.3 Start Date 


9.3.1 Behavior 


The first date which is authorized to bill for the item. This should default to the sfert date in the 


w Authorization Information above. 


9.3.2 Validation 

Standard date formatting, 
jjl Must be a date within the range of pickup date and return date. 

H Requires a status of "Authorized'* 


9.3.3 Business Exceptions 
None. 

9.3.4 System Exceptions 
None. 

9.4 End Date 

9.4.1 Behavior 

The end date should default to the end date of the authorization above. Provided that it is the same, when 
the end date of the "master authorization" is changed, the end date should change for each item with a 
matching end date. 

9.4.2 Validation 

Standard date formatting. 

Must be a date which is equal to or after the Start Date for the item authorized. 
Requires a status of "Authorized" 
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9. 4. 3 Business Exceptions 
None. 

9. 4.4 System Exceptions 
None. 

9.5 Amount 

9.5.1 Behavior 
Text field. 

9.5.2 Validation 
None. 

9. 5. 3 Business Exceptions 
None. 

H 9-5.4 System Exceptions 


p 

SH.3 


None. 


9.6 Tax 

H 9. 6.7 Behavior 


hi 


Drop down to indicate either "included" or "plus tax". Should default to "included; 


u 9.6.2 Validation 


Required for each row where an item is selected. 


jjt 9.6.3 Business Exceptions 
O None. 

9. 6. 4 System Exceptions 
None. 

10. Account Sea rch Screen 

10.1 Overall Note 

This screen is called from the Bill-to screen. These notes are inte nded to highlight to overall functionality, 
hut mav not reflect the most up-to-date changes. See the use case and screen spec for Account Search for 
the most a ccurate information. 

10.2 Group 

10.2.1 Behavior 

This is a drop-down to limit the scope of the search. 

10.2.2 Validation 

Anv grou p present in the dr op down is valid for search. 

10.2.3 Business Exceptions 
None. 
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10.2.4 System Exceptions 
None. 

10.3 Account Name 

10.3.1 Behavior 

The information in the text field is used in associ ation with the "Account Phone Number" and "Account 
Type" to limit the scope of the search. 

10.3.2 Validation 

The field is optional 
The field defaults to blank. 

10.3.3 Business Exceptions 
None. 

10.3.4 System Exceptions 


Q None. 


is:? 

5Se 


10.4 Account Phone Number 


3 !! 


□ 10A.1 Behavior 

Q The information in the text field is used in association with the "Account Name' 

Ul limit the scope of the search. 

U 10.4.2 Validation 

The field is optional. 

The field defau lts to blank. 

*f 10.4.3 Business Exceptions 
None. 

10.4.4 System Exceptions 
None. 

10.5 Account Type 

10.5.1 Behavior 
Dron down. 

The information is used in a ssociation with the "Account Phone Number" and "Account Name" to limit the 
scope of the search. 

10.5.2 Validation 
The field is o ptional. 

The field defaults to "AlF. 

10.5.3 Business Exceptions 
None. 
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10.5.4 System Exceptions 
None. 

10.6 Search Button 

10.6.1 Behavior 

Executes the search using the criteria entered above. 

10.6.2 Validation 
None. 

10.6.3 Business Exceptions 
None. 

10.6.4 System Exceptions 
None. 

10.7 Reset Button 

g io.7.1 Behavior 

j| Clears the screen of the p revious search ( if applicable^) and clears the "Account Name". "Account Phone 

2 Number", and "Account Tvne" fields. 

^ -fO.7.2 Validation * 
w None. 

; : 

!!! 70.7.3 Business Exceptions 
None. 


70. 7. 4 System Exceptions 
None. 

10.8 Cancel Button 

10.8.1 Behavior 

Returns to the s creen from which the search was called. No account name or number is r 

10.8.2 Validation 
None. 

10.8.3 Business Exceptions 
None. 

10.8.4 System Exceptions 
None. 

10.8.5 Validation 
None. 

10.8.6 Business Exceptions 
None. 
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10.8.7 System Exceptions 
None. 

10.9 Page Numbe rs (Hyperlinks) 

10.9.1 Behavior 

Positions the list t o the page selected, or to the "Previous" or "Next" page, if selected. 

10.9.2 Validation 

These should not be hyp erlinks, if no more than one page of Accounts were returned, fie. If only one page 
of accounts is displayed, then th e "Prev" "Nex t" will display on either side of the number "1". and none of 


10.9.3 Business Exceptions 
None. 

5 10.9.4 System Exceptions 
m None. 


5 SB a? 

-1 

51 


11. Not on File 
11.1 Note 


International considerations have not yet been made. 


11.2 Name 


A 11.2.1 Behavior 

ill 


in 


company. 


0 1 f!2.2 Validation 

f ; This field is required. 

11.2.3 Business Exceptions 
None. 

11.2.4 System Exceptions 
None. 

11.3 Address 

11.3.1 Behavior 

Text field to enter the company's address. 

11.3.2 Validation 

All address formatting rules apply. This field is required. 

11.3.3 Business Exceptions 
None. 

11.3.4 System Exceptions 
None. 
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11.4 zm 

11.4.1 Behavior 

Text field to enter the company's zip code. 

714.2 Validation 

All address f ormatting rules appiv. This field is required The zi p code can he entered and then the user 
can use the button behind the field to search for the Citv and State information. Complies with standard 
address for matting, etc... 

11.4.3 Business Exceptions 
None. 

11.4.4 System Exceptions 
None. 

3 , 115 Phone 

O 11.5.1 Behavior 

\zt Text field to enter the company's phon e number. 


11.5.2 Validation 



J- AH phone number formatting rules apply. This field is required 

'Hi 

m 11.5.3 Business Exceptions 

J b1 None. 

ill 

™* 11.5.4 System Exceptions 

| y 

Hi None. 

11.6 


S 3 


fl&f Behavior 

Text field to enter 1 

116.2 Validation 

All address formatting rules apply. This field is required. 

116.3 Business Exceptions 
None. 

116.4 System Exceptions 
None. 

11.7 State 

11.7.1 


Dro p-down field to enter the c ompany 9 s state. 

117.2 Validation 

All address fo rmatting rules apply. This field is required. 
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11.7.3 Business Exceptions 
None. 

11.7.4 System Exceptions 
None. 

11.8 Contact Last Name 

11.8.1 Behavior 

Text field to enter; 

11.8.2 Validation 
This field is required. 

11.8.3 Business Exceptions 
None. 

11.8.4 System Exceptions 


!*j None. 

11.9 Contact First Name 


w 11.9.1 Behavior 

■ ■ I. ■ ■ ■ ■!■ ■ i ■■ ■ 

Text field to enter an individual's first name. 


I' 11.9.2 Validation 

SIS* 

pj This field is required. 

flj 

11.9.3 Business Exceptions 

i*% None. 

719.4 System Exceptions 
None. 

12. Add Contact 

12.1 Last Name 

12.1.1 Behavior 

Text field to enter an individual's last name. 

12.1.2 Validation 

Either of the two fields is required. 

12.1.3 Business Exceptions 
None. 

12.1 A System Exceptions 
None. 
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12.2 First Name 

12.2.1 Behavior 

Text field to ent er an individu al's first name. 

12.2.2 Validation 



12.2.3 Business Exceptions 
None. 

12.2.4 System Exceptions 
None. 

13. Rates Table 

13.1.1 Behavior 

?! This table displays the car classes and rates for the bi ll-to account For display purposes, international 

g considerations for tiered rates have not vet been taken into account, although the functionality is described 

!:! in the "Rate List Button" text above. 

fly ~ ~~~ 

The user can select an amount / car clas s to be authorized bv clicking a car class. 

5 73.12 Validation * 


14. Rules 
14.1 Tabbing 

Tabbin g between fields should be in the order that thev are in this document. 

15. Security 

The user must h ave the appropriate security level to access this screen. 


Confidential ©<Company Name>> 2000 Page 30 of 34 

Y:\GROUPS\E-Commerce Group\Patent Materials 8_3 1 J)l\Copy of All Patents\ECARS20 - Open Ticket\Supp 
Specs\Bill-To.SUP 


None. 


13.1.3 

Hi 

01 13.1.4 


Business Exceptions 
None. 


System Exceptions 
None. 
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1 6. System Generated Notes Table (as of 6 August, 2001 ) 




c TOentagenerate in 
: Reservation 

When to generate . 
in Open 

>Use,Case/J 

nation becomes an open ticket 

'Ticket Opened" 


Create 

Oper 

icket is opened, the information 
sference field will be generated as 

Any text within the preference field 


Create 

Oper 

irkpt iq nnened the text in the 
licle notes, will be generated as a 

Text in the field "Vehicle Notes" 


Create 

Oper 

ntirvn ic msit^VipH f\V llTimfltched tO 

CtLlUll lO illdlvllOU. VI Ui.JUllClvVI.lVU. 

Reservation # "XXXXXX" was (un) 
matched to Ticket # "XXXXXX". 


Create/Edit 

Oper 

ation is created 

"Reservation Created" 

Create 


Creat 

marks jup AKMb otatus Dialog 
Renter flas Been Contacted'' 

jvcuLCi nab Dvvil wuillavicu t\\r\\-> oiiy 

text entered in the ARMS Notes field 

Edit 


Navigation/ 
Dialog I 

marks jfjp ARMS Status Dialog 
Renter tf&s Not Been contacted 

"Renter Has Been Contacted" AND any 

Edit 


Navigation/ 
Dialog I 

5rvatioi£Sick-up date is changed 

■TS 

S 5 

Pick-up Date "XX/XX/XXXX" was 
changed to "XX/XX/XXXX' 

Edit 

i 

Create (if selected 

in the 
Reservation) /Edit 

Rates/D; 

srvatiodTPick-up time is changed 

si 

2 » 

Pick-up Time "XX: XX" was changed to 
"XX: XX' 

Edit 

Create (if selected 

in the 
Reservation) /Edit 

Rates/D; 

ervation Jick-up method is 

a*™ 
v.? " 

Pick-up Method "XX" was changed to 
"XX". 

Edit 

Create (if selected 

in the 
Reservation) /Edit 

Rates/D; 



ervatiortf ick-up location is 

Pick-up Location "XXXX' was changed 
to "XXXXX" 

Edit 

Create (if selected 

in the 
Reservation) /Edit 

Rates/D; 

ervation Return date is changed 

Return Date "XX/XX/XXXX" was 
changed to "XX/XX/XXXX" 

Edit 

Create (if selected 

in the 
Reservation) /Edit 

, Rates/D; 

ervation Return time is changed 

Return Time "XX: XX" was changed to 
"XX: XX" 

Edit 

Create (if selected 

in tiie 
Reservation) /Edit 

Rates/D; 

ervation return method is changed 

Return Method "XX" was changed to 
"XX". 

Edit 

Create (if selected 

in the 
Reservation) /Edit 

Rates/D; 

e Source and/or Account Number 
iged 

Rate Source "XXXXX' was changed to 
"XXXXX" 

Edit 

Create (if selected 

in the 
Reservation) /Edit 

Rates/D; 

e Type is changed 

Rate Type "XXXX" was changed to 
"XXXX" 

Edit 

Create (if selected 

in the 
Reservation) /Edit 

Rates/D; 

• Class is changed 

Car Class "XXXX" was changed to 
"XXXX" 

Edit 

Create (if selected 

in the 
Reservation) /Edit 

Rates/D; 
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ite source and car class has been 
he user manually changes any of 
s populated in the vehicle rate 


rvation return location is changed 


Hote'Te^;. r : y;: / ^/7^ : V; 


What rate values, were changed and what 
the old and new values are. 


Return Location "XXXX" was changed to 
"XXXXX" 


When ^generate fifr 
Reservation^ 


Create/Edit 


Edit 


Whejn to generate 
inQpen 


Create/Edit 


Create (if selected 

in the 
Reservation) /Edit 


Use Case/5 


Rates/D: 


Pick-u 
Locati< 


xp or Branch of the Reservation 
ocation is changed 


Pick-up Location "GPBR" was changed 
to "GPBR" 


Edit 


Create (if selected 

in the 
Reservation) /Edit 


ap or Branch of the Reservation 
ation is changed 


Return Location "GPBR" was changed to 
"GPBR" 


Edit 


Create (if selected 

in the 
Reservation) /Edit 


Pick-u 
Locati* 


Pick-u 
Locati< 



an has f&pulated the products 
r a rate squrce has been chosen 
iser manually changes any of the 


What values were changed and what the 
old and new values are. 


chooses to "Rent" when a renter 
p "Re nter Warning" 
choose^ to bypass the warnuig 
iriver's^ie is either over 70. 21- 
-20 yeajfof age. 


r changes" any phone number of 
r or an additional driver. 


What Values were changed:and, what the 
old and new values are. 


Create (if populated by 
Driver search)/Edit 


r changes any renter or additional 
first or last name 
adds or deletes an additional 


What values were changed and what the 
old and new values arje 
Driver "Last Name, First Name" was 
removed 


Create/Edit 
Create/Edit 


r changes the Referral Account 


r changes the referral contact, 
erral account is the same) 


Referral Account "XXXXX" was 
changed to "XXXXXX" 

Referral Contact "XXXX" was changed 
to "XXXX" for Referral Account 
"XXXX" 


Edit 


r adds a "not on file" contact 
r changes the bill-to account. 


Not on File Contact "First Name, Last 
Name" was added for Referral Account 
"XXXXX". 

Bill-to "XXXX" was changed to 
"XXXX". 


r changes the bill-to contact. (The 
account is the same) 


Bill-To Contact "XXXXX" was changed 
to "XXXX" for Bill-to account "XXXX" 


Create/Edit 


Create (if data 
exists from the 
reservation) /Edit 


Create/Edit 

Create (if data 
exists from the 
reservation) /Edit 


Create (if data 
exists from the 
reservation) /Edit 
Create (if data 
exists from the 
reservation) /Edit 


Edit 


Create/Edit 


Create (if data 
exists from the 
reservation) /Edit 


Products 
Discoui 


Create (if data 
exists from the 
reservation) /Edit 


Basic Res/] 


Basic Res/) 
Basic Res/1 


Referr 


Referr 


Bill-ti 
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adds a "not of file" bill-to 


Note.TextL ^;v£:W£V ^?^-'^ 


^lento geneiste nv . 

X £ >:Kesem&om ; V' U '- 


: ^ea to generate 


UseCase/S 


Not on file contact "First Name Last 
Name" was added for Bill-to Account 
"XXXXX" 


Create/Edit 


Create/Edit 


changes the authorized by 
(The Bill-to account is the same) 


Authorized By "XXXX" was changed to 
"XXXX" for Bill-to Account "XXXXX" 


Edit 


Create (if data 
exists from the 

reservation) /Edit 
Create (if data 
exists from the 

reservation) /Edit 


Bill-t» 


changes the auth status. (The 
xount is the same) 


The Authorization Status was changed 
from "XXX" to "XXXX" for Bill-to 
account "XXXXX" 


Edit 


changes the auth %. (The Bill-to 
is the same) 

changes the Max Per day. (The 
ccount i&£he same) 


IT'! 


The Authorization % was changed from 
"XX" to "XX" for Bill-to Account 
'XXXX" 

The Maximum Amount Per Day was 
changed from "XX" to "XX" for Bill-to 
Account "XXXX" 


Edit 


Edit 


changqjSJthe Max Billable 
(The Bill-to account is the same) 


• changfsjhe number of days. 
1-to account is the same) 


4* 


J- 


The Maximum Billable Amount was 
changed from "XX" to "XX" for Bill-to 
Account "XXXX" 
The number of days was changed from 
"XX" to "XX" for Bill-to Account 
"XXXXX" 


• changes either the Billing start 
)illing start time (The Bill-to 
is the sanae) 


r chang||{either the Billing end 
rilling #d time. (The Bill-to 
is the spfiie) 


The Billing Start Date and Billing Start 
Time changed from "XXXXXX" to 
"XXXXXXXX' for Bill-to Account 
"XXXXX" 
The Billing End Date and Billing End 
Time changed from "XXXXXX" to 
"XXXXXXXX' for Bill-to account 
"XXXXX". 


Edit 


Edit 


Edit 


Edit 


r changes the daily rate. (The Bill- 
int is the same) 


The Daily Rate was changed from 
"XXXX" to "XXXX" for Bill-to account 
"XXXX" 


r changes the Authorized Car 
;The Bill-to is the same) 


The Authorized Car Class was changed 
from "XXXX" to "XXXX" for Bill-to 
account "XXXXX". . 


r changes the Plus Tax check box 
11-to account is the same) 

r changes a product or service (The 
is the same) 


What the check box was.and what it was 
change d to 

What Products were added or deleted and 
the amounts they were changed from and 
to. 


r adds a Not on File Bill-to 

r changes the Ro/Po/Cl #. (The 
is the same) 

r changes the Claim type. (The 
is the same) 


Not on File Account "XXXX" has been 
added as a Bill-to 

The RO/PO/CL # was changed from 
"XXXXX" to "XXXX" for Bill-to 
account "XXXXX" 
The Claim Type was changed from 
"XXXX" to "XXXX" for Bill-to account 
"XXXXXX" 


Edit 


Create (if data 
exists from the 
reservation) /Edit 
Create (if data 
exists from the 
reservation) /Edit 


Create (if data 
exists from the 

reservation) /Edit 
Create (if data 
exists from the 

reservation) /Edit 


Create (if data 
exists from the 
reservation) /Edit 

Create (if data 
exists from the 
reservation) /Edit 


Edit 


Edit 


Create/Edit 


Create (if data 
exists from the 
reservation) /Edit 


Create (if data 
exists from the 
reservation) /Edit 


Create/Edit 
Edit 

Mt~ 


Create (if data 
exists from the 
re servation) /Edit^ 
Create/Edit 


Create/Edit 

Create (if data 
exists from the 
reservation) /Edit 
Create (if data 
exists from the 
reservation) /Edit 


Bill-ti 


Bill-* 


Bill-t< 


Bill-* 


Bill-to 


Bill-ti 


Bill-ti 


Bill-ti 


Bill-ti 


Bill-ti 


Bill-to 


Bill-to 
Bill-to 

Bill-to 
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: NoteText* : • < ]r 'l^: ^J/;] j \> ; [ 

4 ; * .When to generate jn, ^ 

:v '-° - Reservation:' ,v ; , ' 

, KWhea; ttf generate; 

\tlse Case/5 

• changes the insured's name. 

The Insured's Name was changed from 
"XXXXXX" to "XXXXXX" 

Edit 

Create (if data 
exists from the 
reservation) /Edit 

Bin-* 


n 

'5 . 

hj 

14* 

HJ 
si's 

« 

War- 
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r™ 
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Table of Contents 


1. Introduction 


2. Screen Print 


1SS 


3. Top (see Figure 1) 

3 . 1 Years at current address 

3.1.1 Behavior 

3.1.2 Validation 

3.1.3 Business Exceptions 

3 . 1 .4 System Exceptions 

3 .2 Months at current address 

3.2.1 Behavior 

3.2.2 Validation 
J 3.2.3 Business Exceptions 

3 .2.4 System Exceptions 
fljj 3.3 Ownership 
jyi 3.3.1 Behavior 

g 3.3.2 Validation 

11 J 3 .3 .3 Business Exceptions 

14 3.3.4 System Exceptions 

4. Employment Verification (see Figure 1 ) 

4.1 Employer 
III 4.1.1 Behavior 
y% 4.1.2 Validation 

j«i 4.1 .3 Business Exceptions 

j'J 4.1.4 System Exceptions 

4.2 Position 

4.2.1 Behavior 

4.2.2 Validation 

4.2.3 Business Exceptions 

4.2.4 System Exceptions 

4.3 Supervisor's Name 

4.3.1 Behavior 

4.3.2 Validation 

4.3.3 Business Exceptions 

4.3.4 System Exceptions 

4.4 Spoke to Whom 

4.4.1 Behavior 

4.4.2 Validation 

4.4.3 Business Exceptions 

4.4.4 System Exceptions 

4.5 Years at Employer 

4.5.1 Behavior 

4.5.2 Validation 

4.5 .3 Business Exceptions 

4 .5 .4 System Exceptions 

4.6 Months at Employer 
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V$2? 

1 y 


S w 

01 

".« ■ 
ii s 


4.6.1 Behavior 

4.6.2 Validation 

4.6.3 Business Exceptions 

4.6.4 System Exceptions 

5. Rental Information (see Figure 2) 

5.1 Reason for Renting 

5.1.1 Behavior 

5.1.2 Validation 

5.1.3 Business Exceptions 

5. 1 .4 System Exceptions 

5.2 Rented Previously 

5.2.1 Behavior 

5.2.2 Validation 

5.2.3 Business Exceptions 

5.2.4 System Exceptions 

5.3 If so, when? 

5.3.1 Behavior 

5.3.2 Validation 

5.3 .3 Business Exceptions 

5.3.4 System Exceptions 

5 .4 Do you own a car? 

5.4.1 Behavior 

5.4.2 Validation 

5.4.3 Business Exceptions 

5.4.4 System Exceptions 

6. References (see Figure 2) 


6.1 


6.2 


6.3 


7. 


First Name (column) 

6.1.1 Behavior 

6.1.2 Validation 

6. 1 .3 Business Exceptions 

6. 1 .4 System Exceptions 
Last Name (column) 

6.2.1 Behavior 

6.2.2 Validation 

6.2.3 Business Exceptions 

6.2.4 System Exceptions 
Phone Number (column) 

6.3.1 Behavior 

6.3.2 Validation 

6.3 .3 Business Exceptions 

6.3.4 System Exceptions 
Relationship (column) 

6.4.1 Behavior 

6.4.2 Validation 

6.4.3 Business Exceptions 

6.4.4 System Exceptions 


Authorized By 
7.1 User ID 


6.4 


11 
11 
11 
11 

11 

11 

11 

11 

12 

12 

12 

12 

12 

12 

12 

12 

12 

12 

12 

12 

12 

12 

12 

12 

13 

13 

13 

13 

13 

13 

13 - 

13 

13 

13 

13 

13 
13 
13 
13 
13 
14 
14 
14 
14 
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14 
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7. 1 .4 System Exceptions 

14 

7.2 Password 

14 

7.2.1 Behavior 

14 

7.2.2 Validation 

14 

7.2.3 Business Exceptions 

14 
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14 
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15 

R ] OftTlCP] HllttATl 

liVrnr' Rnnkmark nut Hpfiii^fJ 

XL, 1 1 \Jl a JJvJvJIV* Hell IV 11 VI UdlllbVI* 

8.1.1 Behavior 

Error! Bookmark not defined. 

8.1.2 Validation 

Error! Bookmark not defined. 

o.x.j rsusiness exceptions 

Jdirror. uooKnidrK not uciineu. 

o. I ,*f oysiem isxcepxions 

terror: uooKmarK not uennea. 

9. Note for OPEN (vs. Reservation) 
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jj 


II 


Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the Insurance Details screen. 

The, system must be ahle to distinguish, presumably hv the terminal ID. the proper screen lansuz 
presentation as well as any field formatting applicable to that particular locale. 

2. Screen Print 


Drivers - Cash Qualification 


DRIVERS 


James Atteberry 
Additional Drivers: 2 


REFERRAL 


Account Name 
Contact Name 


DATES /RATES 


08/27/2001; ECAR 
Daily Rate; ASD 


BILL-TO 


Account Name 
Contact Name 


VEHICLE/SHOP 


1997 Dodge Avenger 
Shop Account Name 


Notes Taken: 1 
Changed: 08/27/2001 


[-Options- 



Atteberry, 
\-\ James : 


I Smith, 

Cloud, 

[: Chris 

Kevin [ 


Driver 


Other Address 


Insurance Detail 


Cash Qualification 


-Cash Qualification 

How long at the current address: 

Ownership: 


J Years 
Months 


f Employment Verification- 
Employer 


Position 


[ 


Supervisor's Name 


Spake To Whom 


How Long? 
|Q it Years 

j0 H Months 


Rental Information ~ ~~ ' 

Reason for Renting: G Car In Shop 

O Weekend 


Rented Previously: 


y 


-V 



Res- 411701 


Tkt - 234567 [ Cbk - 36322 1 ] 


Fi gnrel - Cash Qualification Address & Eirpinympnt Verification 
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lei 


s 3 
flj 

m 


til 

a 

5! . 


{ gCagfaQttall - Microsoft Iirtttrnet Explorer provided by Enterprise Rent-a-Car 



Prkt - 234567 [Cbk - 36322 1] 

Figure 2 - Cash 
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iSilllll 


F:\html\ReservQtton\Navi9(3tion\TMP9<aaurj71pj htm 



ft 1 ? 


Referral sum 1 
Referral sum 2 


DATES/RATES 


Dates summary 1 
Dates summary 2 

Bill-To summary 1 
Bill-To summary 2 


VEHICLE/SHOP 


Vehicle/Shop 1 
Vehicle/Shop 2 

Notes summary 1 
Notes summary 2 


O Other [ 


Do you own a car? 


'<<t 


"3 J 


«£1 


pReferences (Three Different People) - 

First Name Last Name 

i. l t EZZZZ 

2. * 


Phone Number Relationship 


3-[ 


p Authorized By 

User Id Password 

CD 


Res - 411781 


Tkt - 234567 


Cbk - 363221 


Figure 3 - Cfi *h Qualification 


1 , 


m 
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3. Top (see Figure 1) 

3.1 Years at curr ent address 

3.1.1 Behavior 

This is a dron down list of integers and rem. The d rop down should start at Q and po through 9, followed 

3. 1.2 Validation 

No validation is necessary. The field is ontional. 

3. 1.3 Business Exceptions 

None have been identified at this time. 

3. 1.4 System Exceptions 

None have been identified at this time. 


n> 3.2 Months at current address 


J 3.2.1 Behavior 

P. This is a drop down list of integers and zero Th P Hmp down should start at 0 and go through 1 1 . 


iU 


a 


3.2.2 Validation 
No validation is necessary. The field is 

3. 2. 3 Business Exceptions 

None have been identified at this time. 

3.2.4 System Exceptions 

None have been identified at this time. 

3.3 Ownership 

3.3.1 Behavior 

Thk k a dro p down list of two values (o wn A renft plus « Wank. Since the selection is optional, it should 
default to blank. 

3.3.2 Validation 


3. 3. 3 Business Exceptions 

None have been identified at this time. 

3.3.4 System Exceptions 

None have been identified at this time. 
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4. Employment Verificatio n (see Figure 11 

4.1 Employer 

4.1.1 Behavior 

This is an alphanumeric field. 

4.12 Validation 

No validation is necessary. The field is optional. 

4.1.3 Business Exceptions 

None have been identified at this time. 

4.1.4 System Exceptions 

None have been identified at this time. 

4.2 Position 


4.2.1 Behavior 
01 This is an alp hanumeric field. 


y 4.2.2 Validation 

No validation is necessary - The field is optional. 

s 

h*. 4.2.3 Business Exceptions 

hJ None have been identified at this time. 

ill 

P 4.2.4 System Exceptions 

M None have been identified at this time. 

4.3 Supervisor's Name 

4.3. ? Behavior 

This is an alphanumeric field. 

4.3.2 Validation 

Nn validation is ne cessary. The field is optional. 

4. 3. 3 Business Exceptions 

None have been identified at this time. 

4.3.4 System Exceptions 

None have been identified at this time. 

4.4 Spoke to Whom 

4.4.1 Behavior 

This is an alphanumeric field. 
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4.4.2 Validation 
No validation is necessary. The field is optional. 

4. 4. 3 Business Exceptions 
None have been identified at this time. 

4.4.4 System Exceptions 
None have been identified at this time. 

4.5 Years at Employer 

4.5.1 Behavior 

This is a dr op down list of integers and zero. The drop down 
bv"10+". 

U 4.5.2 Validation 

O No validation is necessary. The field is optional 

O 

111 4.5.3 Business Exceptions 

d) None have been identified at this time. 

s i 4.5.4 System Exceptions 
m None have been identified at this time. 


7.. —A 


4.6 Months at Employer 

4.6.1 Behavior 

This is a dron down list of integers and zero. The drop down should start at Q and go through 1 1 . 


M 4.6.2 Validation 

No valida tion is nec essary. The field is optional. 

4. 6. 3 Business Exceptions 

None have been identified at this time. 

4. 6. 4 System Exceptions 

None have been identified at this time. 

5. Rental Inform ation (see Figure 2) 

5.1 Reason for Renting 

5.1.1 Behavior 

This is a choice among four valu es: Car in Shoo, 
optional it should default to nothing, selected. 

5.1.2 Validation 

The selection and description are optional. 


rtion. and Other. Since the selection is 
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If Other is selected, then the field next to it is enabled to allow a description. The description is not 
required. 

5.1.3 Business Exceptions 

None have been identified at this time. 

5.1.4 System Exceptions 

None have been identified at this time. 


5.2 Rented Previously 

5.2.1 Behavior 

This is a drop down of twc 
to blank. 


Hon is optional it should default 


■a 5.2.2 Validation 

The selection and description are optional 


5. 2. 3 Business Exceptions 

None have been identified at this time. 


y 5.2.4 System Exceptions 

None have been identified at this time. 


•i .a 


JIM 
sis s 


5.3 If so. when? 

Hi 

flj 5.3.7 Behavior 


jjlSisi 


allow an answe r. The answe r is not required. 

5.3.2 Validation 
The selection an d description are optional 

5.3.3 Business Exceptions 
None have been identified at this time. 

5. 3. 4 System Exceptions 
None have been identified at this time. 

5,4 Dn you own a car? 


5.4.1 Behavior 

This is 
to blank. 


/alues (Yes & Nq) and; 


5.4.2 Validation 

The selection is optional 

5. 4. 3 Business Exceptions 

None have been identified at this time. 


islv" is Yes, the 


^rinnal. it should default 
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5. 4. 4 System Exceptions 

None have been identified at this time. 


6- References (see Figure 2) 

This section is not a dyna mic list but ra ther a set of 3 names and associated information (below) which can 
he entered bv the user. 

6.1 First Name icotumnl 

6.11 Behavior 

This is an alphanumeric field. 

6.12 Validation 

No validation is necessary. The field is optional. 

6.13 Business Exceptions 
None have been identified at this time. 


Hi 


O 


¥> 

x'S 5 
r, i; = 
; ?3T 


6. 1.4 System Exceptions 

None have been identified at this time. 

6.2 Last Name (column! 

6.2.1 Behavior 


W 6.2.2 Validation 


% No validation is necessary. The field is optional. 


^ 6.2.3 Business Exceptions 


None have been identified at this time. 


6. 2. 4 System Exceptions 

None have been identified at this time. 


6.3 Phone Number (column) 

6.3.1 Behavior 

This is an alphanumeric field. I t should com ply with the st andard phone number field formatting, 
m6/05/20Ql- To da te, no European considerations have been noted (waiting on update to Use Case). 

6.3.2 Validation 

The field is optional. 

Tt should be edited to comply with the locale's format fi.e. in the United States, the length is 10 digits and^ 
include delimiters after the 3 rd and 6 th characters, Tf no delim iters are used, but 10 digits are entered, that is 
also valid.) 

6.3.3 Business Exceptions 

None have been identified at this time. 
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6. 3. 4 System Exceptions 

None have been identified at this time. 

6.4 Relationshi p (column! 

6.4.1 Behavior 

This is an alphanumeric field. 

6.4.2 Validation 

No validation is necessary. The field is optional. 

6. 4. 3 Business Exceptions 

None have been identified at this time. 

6. 4. 4 System Exceptions 

None have been identified at this time. 

7. Authorized By 
7.1 User ID 

7. 1. 1 Behavior 

This is an alphanumeric field and should conform to the standards for User ID. 

7.1.2 Validation 

Must be a valid employee, authorized to the Rental Application. 


ifi 7.13 Business Exceptions 

None have been identified at this time. 


H 


is;;?! 


7. 1 4 System Exceptions 

None have been identified at this time. 

7.2 Password 

72. f Behavior 

This is an alphanumeric field and should conform to the standards for Passwords. 

7.2.2 Validation 

Must be the employee's password. 

7. 2. 3 Business Exceptions 

None have been identified at this time. 

7. 2. 4 System Exceptions 

None have been identified at this time. 
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8. Button Line Area 

8.1 Back Button 

8. 1 1 Behavior 

The Back button will take the user to the main Driver screen for the currentl y selected Driver. 

8.12 Validation 

None identified at this time. 

ft 1.3 Business Exceptions 

None identified at this time. 

8.1.4 System Exceptions 

None identified at this time. 

8.2 Complete button 


*5RS? 

n 

rut 


8.2.7 Behavior 

The Com plete button will initiate a save of the transaction. All va lidations will be performed, returning anv 
errors to the user. Tf there are no errors, the tran saction is saved, and the user is returned to the Reservation 
home page. 

O 8.2.2 Validation 
'i None identified at this time. 


v.r 
j ail 


111 

fi I 

i 

s - 

is- 

u 


8.2.3 Business Exceptions 
M None identified at this time. 

8. 2. 4 System Exceptions 
p* s None identified at this time. 

9. Note for OPEN ( vs. Reservation) 

Password and employee ID will be added at the bottom for authentication of the person authorizing the 
Cash Qualification. 

10. Rules 

10.1 Required Fields 

There are no required fields . 

10.2 Tabbing 

Tabbing between fields should be in the order tha t thev are in this document. 

10.3 Saving 

Recause none of the information on the screen is req uired, the user can leave the screen at anv time. The 
save is completed when the user saves the reservation or ticket. 

11. Security 

The user must have the appropriate security level to access this screen. 
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1. Basic Reservation 
11 Brief Description 

The use case describes the interac tion between the user and the system when a renter calls and the user 
captures ren ter and additional driver information 

2. Flow of Events 
2.1 Basic Flow 


2.11 The system displays rent er information fields to be c ompleted b v the user. 
The following is the list of fields to be co mpleted bv the user: 

Most comm only entered information (North America): 
Last Name 


Hm Phone 
Wk Phone 
Extension 
Other Phone 
Phone Description 


Less commonly entered in formation (N orth America): 
Addxess 

m 

Country 


State 

Other Address 
Employer 
License Number 
Expiration Date 
Country Issued 
State Issued 
DOB (Date of Birth) 


SSN 

Height -Feet 
Height - Inches 

Hair Color 
Eye Color 


Note: Primary payment method is part of the above list but will not be implemented until E2. 

Most commonly entered information (U.K.): 

• Last Name 

• First Name 

• Hm Phone 
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• Wk Phone 

• Extension 

• Other Phone 

• Phone Description 

Less commo nly entered information (U.K.): 

• Address (A 2nd renter address field is added in U.K.) 

• Postal Code 

• Country 

• cm 

• County 

• Other Address 

• Employer 

• Licence Number (note^jffe rence in spelling) 

• Expiration Date 

• Issuing Authority 

• DOB (Date of Birth) 

• National ID (Social Security Number in US) 

• Height - Feet (NOT CAPTURED IN U.K. Germany. Ireland.) 

• Height" tocMs_jN^CAP TURED IN U.K. , Germany JMandl 

• Weight fNQT CAPTURED IN U.K.. Germany. Ireland) 

• Hair Color (NOT CAPTURED IN U.K. Germany. Ireland.) 

• Eve Color (N OT CAPTURE D IN U.K.. G ermany. Ireland) * 

tNote: Primary Payment M ethod (note: "check" is s pelled "chegue") is part of th e above list but will not be 
implemente d until E2. 


2.1.2 Renter has the option ofinitiatino anv o f the followi ng options: 

f NOTE: These options are in order of most freouen tly chosen options to least freguentlv chosen options) 

• Enter data for above listed fields 

• Add a Referr al Source 

• Quote a rate 

• Add a Pick up/return date and time. 

• Add a car class 

• Special and d iscounts 

• Add Directions 
e Add Notes 

• Add Additional drivers 

• Insurance Detail 

• Cash Qualification 

• Print the reservation 

(Note: The se options are covered in the alternative flows.) 

2.1.3 The user ent ers the abo ve identified r enter information into the reservation. 

2.1.4 The user has the option to "Complete Reservation " or Cancel. If the user c hooses to Exit the 
reservation t he use case continues at alternativ e flow (Cancel). 

2.1.5 The system v alidates the in formation ente red, as determined bv the business rules: 

• If the driver's license is e xpired, the use case contin ues at alternative flow (Driver's License 
Expiration date). 
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2.16 

2.2 

2.2.1 

2.2.1.1 


If the age for DOB entered is over 70. the use case c ontinues at alternative flow (Over Ag e 
Restriction). 

if the aae for DOB is 18-20. the use case c ontinues at alternative flow (U nder Aae 18-20 Soft Edit 
Restriction!. 

If the aae for DOB is 21-24. the use case continues at alternative flow (Under Aae 21-24 Soft Edit 
Restriction^ 

If the aae for the DOB entered is under 18. the us e case continu es at alternative flow (Under Age 
Rental Restriction). 

If all of the driver's license related fields are not entered along with the driver's license number. 
the use case continues at alternate flow (Drive rs License re quirements!. 

If the user has not captured the minimum required information of Last Name, the use case 
continues at alternative Flow (Incomp lete Reservation! 

If anv additional driver h as a warning attached to it's file in the repeat renter d atabase, the use 
case extends to the alternative flow (Renter Warning) in the Create Reservation use case and 
then the Renter use case continues. 

The use case ends. 
Alternative Flows 


Drivers License Requirements 

If the user enters a driver's license number, the following reouired informat ion must also be 
entered: otherwise the system displays an error message that additional information is needed: 

Driver's license e xpiration date 
State issued 


Date of birth 


2.2.1.2 


2.2.1.3 


If the user ente rs anv of the driver's license information other than the driver's license number 
and does not enter the driver's license number the system will display an error message that 
additional information is needed. 

If the user enters any of the non-required driver's lic ense information (SSN. height weight eve 
color, or hair color) without also entering th e re guired driver's license information, the system 
will not display an error message that additional information is needed and the use case 
continues. 

2.2.2 Add Additi onal Drivers. 

2.2.2.1 


Name: 


The system displays the area for entry of the first and last name in formation of the additional 
driver. The fields in this area are: 

First Name 


Address: 

• Street Address 

• Zip/Postal Code 

• Country 
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• QM 

• State/Province 


Phone Number: 

• Home Pho ne Number 

• Work Phone Number (a nd extension) 

• Other Phone Number tend ohone type) 

Driver's License; 

• Driver's Lic ense Number 

• Driver's Licen se Expiration Date 

• State Issued/issuing Authority 

• Date of Birth 

• Social Security Number 

• Height 

• Weight 

• Hair Color 

• Eve Color 


2.2.2.2 The user enters the first and last name of the additional driver and the home phone number. 

2.2.2.3 The system displays the iigtioJiforthe user to sele ct that the additional dri \^iJhasJb^s ame 

alternate flow. 

2.2.2.4 The user ent ers the street address and zip/postal code. 

2.2.2.5 Based upon the zip/postal code search the system produces the ci tv and state/province. 
populates the correspon ding fields and continue s at the nex t step in the basic flow. The system 
also makes the information in these fields available for edit. If th e search produces no 
matching citv and state/ province information the u se case co ntinues at alternate flow (No Match 
to Zip/Postal Code). 

2.2.2.6 The user ent ers additional driver information from the table above (2.2.5.1) 

2.2.2.7 The system displays th e option for the user to: 

• Add more additional driver s. (The system allows the user to enter u p to 5 additional 
drivers to the reservation) 

• Delete ad ditional driver information 

• Exit and return to the ba sic flow. 

2.2.2.8 If the user selects to add more additional drivers (up to 6). the s ystem adds another blank 
additiona l driver a rea and re turns to t he first ste p of this alternate flo w. If the user selec ts to exit 


the use ca se returns to the point in the basic flow where the user s elected to add the additions 


driver information. 

2.2.2.9 Upon submitting the additional driver p aoe. th e system validates that the minimum reservation 
criteria (Additional Driver's Last Name) has been entered. **Note this validation works as it 
does with the primary driver last name validation 

If the user hag not c aptured the minimum reouired inform ation of Last Name, the use case continues 
at alternative Flow (Incomplete Reservation! 


Confidential ©<Comoany Name>. 2000 


< Project Name> 

Version: <1.0> 

Use Case Specification: <Use-Case Name> 

Date: <dd/mmm/vv> 

<document identifier 



2.2.3 No Match to Zip/Postal Code 

2.2.3.1 The system displays a fe edback message that the entered zio/po stal code and selected 
country do not produce matching citv and state/province information. 

2.2.3.2 The user has the option to: 

• Change the zip/ posta! code and country information and repoouiate. 

• Continue with the reservation process without the citv and state/ province information. 

2.2.3.3 If the user selects to change the zio/postal code the use ca se will continue at t..) in the basic 
flow. If the user elects to continue with the re servation process, the system w ill allow the_user 
to manually enter information into t he city and s tate/provin ce fields and continue at ( ) in the 
basic flow. The system will have the already entered inf ormation pr esent and ready for the user 
to enter the city and to select the state/province. 

(Note on Address Search Results!: 

Based upon the zip/postal code searc h the system produces the citv and state/province. 
populates the corresponding fields and c ontinues at th e next step in the basic flow. The system 
also makes the information in these fields available for edit. 

2.2.4 Multiple Mat ches to Zip/Postal Code 

2.2.4.1 The system displays a message that more than one citv matche s the zip^/post al code entered 
and displays the list of matching cities to the user. 

2.2.4.2 The user h as the option to selec t one of the cities from the list or cancel and continue with the 
reservation. 

2.2.5 Expired Driver's License 

2.2.5.1 The system displays a feedback messa ge "Drivers Lic ense is Expired". 

2.2.5.2 The s ystem prompts t he user to: 

• Change/enter valid expiration date. 

• Cancel. 

2.2.5.3 If the user selects to c han ge the expiration date the u se case proceeds back to Phone and 
Driver's License Information Entry in the basic flow. If the user selects to exit the reservation, 
the use case continue s at alternat e flow (Cancel). 

2.2.6 Over Aae Soft Edit Restriction 

2.2.6.1 The system determines that the aoe of the renter is 7 0 years old or older. 

2.2.6.2 The system displays a feedback message that the entered date of birth results in the age of the 
renter being 70 or older. The system also displays the entered date of birth and the renter's 
age. 

2.2.6.3 The system prompts the user to: 

• Continue with reservation. 

• Enter correct date of birth. 

• Cancel. 

2.2.6.4 If the user elects to continue with the reservation, the use case continues at (2.17) in the basic 
flow. If the user selects to change the date of birth the use case continues at (2.1.3) in the basic 
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flow with the attention planed on the DO B field. If the u ser selects to exit the res ervation, the 
use case continues at alternate flow fCanoen 

2.2.7 Under Aae (18-20) Soft Friif Restriction 


2 - 27 - 1 The system determines that the aae of the renter is 18 to 20 years old. 

2 - 2 - 7 - 2 The system displays a feedback mes sage that the entered date of birth res ults in the aae of the 
renter being 18 to 20 years old. The system also displays the entered date of birth and the 
renter's aae. 

2.2.7.3 The system prompts the user try 

• Continue wit h reservation. 

• Enter correct date of birth. 

• Cancel. 

2.2J.4 If the user elects to conti nue with the reservation, the use case continues at (2.17) in the basin 
flow. If the user selects to ch ange the date of birth the use case continu es at (2. 1.31 in the 
basic flow with attention placed on the DOB field. I f the user selects to exit the res ervation, the 
use case continues at alternate flow ( Cancel). 

2-2.8 Under Aae (21-241 Soft Edit Restriction 

2.2.8.1 The system determines that the age of the renter is 21 to 24 years old. # 

2.2.8.2 The system displays a feedback message that the entere d date of birth r esults in the aae of the 
renter being 21 to 24 years old. The system also displays the entered date of birth and the 
renter's age. 

2.2.8.3 The system prompts the user to: 

• Continue with reservation 

• Enter correct date of birth. 

• CanceL 

2-2.8.4 if the user elects to continue with the reservation, the u se case continues at f2.1.7l in the basic - 
flow. If the user selects to change the date of birth the use case continues at (2. 1 .31 in the 
basic flow with attention placed on the DOB field . if the user sel ects to exit the r eservation, the 
use case continues at alternate flow (Cancel). 

2.2.9 Under Aae Hard Edit Restriction 

2.2.9.1 The system determines that the age of the renter is eoual to or und er the aoe o f 17 years old 
mnd Do Not Rent. 

2.2.9.2 The system displays a feedb ack message that the entered date of birth results in the aoe of the 
renter being under the age restriction. The system also displays the entered date of birth and 
the renter's aoe. 

2.2.9.3 The system prompts the user to: 

• Correct the date of birth. 

• Cancel. 

2.2.9.4 If the user selects to chan ge the date of birth the use case continues at (2. 1 .3) in the basic flow 
with attention pl aced on the DOB field. If th e user selects to exit the reservation, th e use case 
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continues at alte rnate flow fCanrelV 

2.2.10 Incom plete Reservation 

2.2.10.1 The system displays a message notifyin g that the user has not cap tured the minimum required 
information necessary (Renter's Last Name) to cre ate a reservation. ^ ~ 

fNote: The user cannot move the message box to t he side and at tempt to navigate anv area on the 
screen to enter reouired information. Thev must click "OK" to dismiss the message box and enter the 
required information.) 

2.2.11 ElM 

2.2.111 The Renter Call Reservat ion Use Case initiates the Print use case 

2.2.12 Cancel 

2.2.12.1 The user uses the quit function to confir m that thev do not wish to save anv of the information 
that has been entered for a reservation since the last save. 

2.2.12.2 The system prompts the user with a dialog box stating that the reservation will not be saved 
and asking if the user would like to exit the reservation without saving anv of the information 
entered. 

2-2.12.3 The use case continues a t Reservati on Home. 

2.2.13 Add a Pick Up and Return Date 

2.2.13.1 The Renter Reservation use case initiates the Dates use case to add a pick u p/return date and 
time 

2.2.14 Add a Car CJass 

2.2.14.1 The Renter Reservation Use Case initiates the Dates and/or Rates use case. 

2.2.15 Quote Rates 

2.2.15.1 The Renter Reservation Use Case initiates the Q uote a Rat e use case. 

2.2.16 Specials and Discounts 

2.2.16.1 If the rental requires Discount or Special Rate information the use case initiates the Quote a 
Rate Use Case. 

2.2.17 Add a Pick Up Method 

2.2.17.1 The Renter Call Reservation use cas e initiates the Dates use case 

2.2.18 Add Directions 

2.2.18.1 The Renter Call Reservation Use Case Initiates the Dates use case. 

2.2.19 Add Notes 

2.2.19.1 The Renter Call Reservation Use Case initiates the Add Notes use case. 
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2.2.20 

2.2.20. 

2.2.21 

2.2.21. 

2.2.22 

2.2.22. 

3. 

1. 
2. 


m 


; E S 


4. 
5. 

6. 

6.1 


Add Cash Qualification 

1 The Renter Caii Reservation Use Case ini tiates the Cash Qualification use case 
Add Insurance Detail 

1 The Renter Call Reservation Use Case initiates the Insurance Detail use case 
Add a Referral Source 

1 The Renter Call Reservation Use Case initiates the Referral use case 

Special Requirements - Basic Requirements UC 

Bold the labels of required fields or put next to the required fields. 

Issuing Authority has a different validation than Stat e Issued. State issued is a 2-letter code from 
a list of valid values. Issuing Authority is a free-form text field. 

Basic Combo box behavior The use r should enter the letter "M" multiple time to position p ast 
Maine Maryland.. .to Missouri. 

Pre-Conditions 
Post-Conditions 

System Gen erated Notes - Basic Res , , 

Notes should be generate d when the following events take place : 


Evdht 


Note Text 


When to Generate 


The'Oser c hooses to "Rent" when a renter comes up 
"ReHfer Warning" 


amino overridden" 


Create/Edit 


Thd ; Mser chooses to bypass the warning when a driver's 
soeik either over 70. 21-24 or 18-20 y ears of a ge , 
The^ser chances th e Renter's Home phone number 


"Underaoe/Overac 
overridden" 


Creatg/Edjt 


What Values were changed and 
what the old and new values are. 


The User changes any renter or additional driver's first or 
last name 


What values were changed and what 
the old and new values are 


Create fif populated 
by Driver search)/Edit 

Create/Edit 


The user adds or deletes an additional driver 


Driver "Last Name. First Name" was 
removed/ added 


Create/Edit 


The User changes the Work phone number of the Renter. 


Renter "Last name. First name" 
Work Phone was changed from 
"XXXX" to "XXXXX". 


Create fif populated 
bv Driver search)/Edft 


The User changes the Other phone number of the 
Renter . 


Renter "Last name. First Name" 
Other Phone was changed from 
"XXXX" to "XXXXX". 


Create fif populated 
bv Driver search VEdit 


The User c hanges anv Additional Driver's Home phone 
number. 


Additional Driver "Last Name. First 
Name" Home Phone was changed 
from "XXXX" to "XXXXX". 


Create fif populated 
bv Driver se arch VEdit 


The User changes an y Additional Driver's Work p hone 
number . 


Additional Driver "Last Name. First 
Name" Work Phone was chanced 
from "XXXX" to "XXXXX". 


Create fif populated 


The User changes anv Additional Driver's Other phone 
number . 


Additional Driver "Last Name. First 
Name" Other Phone was changed 
from "XXXX" to "XXXXX". 


Create fif populated 
by Driver searchVEdit 
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7. Extension Points 

7.1 <Name of E xtension Point> 

8. 

• Is there a new requirement that ask s to distinguis h the underage edit between 18-20 and 21-24 
instead of the 18-24 sof t edit that is in place no w? Yes 

• Ability to lis t additional drivers as 'With Valid Lie". Do we want to dr ive this behavior in 
Reservation? Free form text to 

• Need to allow some wa y to input or identify if the "Address" field is business or home. Other than 
having home address and other address? 

• Need a ch eck box on the "Addition al Driver" tabs to indi cate if this p erson lives in the same 
household as the renter. In ad dition, there needs to be a compelling r eason for the branch to 
actively pursue this. Has a compelling reason arisen yet? 


Q 
O 
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m 
o 

**3 


m 

.ru 


Need to cap ture the business addr ess and busi ness name as main fields on the "R enter Screen". 
This needs to be integrated with Re nt-a-car requirements and mioht mea n putting the company 
name field iust below driver and then adding a check box to indicate if it is a business address. Is 
there a corporate rental need for this o r iust truck rental? 

Need to be able to attach multip le reservations to one confirmation number. Is t his still a 
business need since reservations are going to be uniq ue and carry forward? 
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Use Case Specification: Reservation Callback 


1. Reservation Callback 

1 .1 Brief Description 

This use case will describe how a user interacts with a system to create a callback flag from within a 
reservation window. It will show the flow of events that occur when a Callback Flag is created. 

2. Flow of Events 

2.1 Basic Flow 

2.1.1 The use case begins when the user has the option to create a callback from within a res ervation 
window. The user h as the o pti on to create a callback for ad juster service, body shoo, or a renter 
callback. Callback flags can be accessed during the creation or update of a reservation . 

2.12 The user chooses to create a cailback flag for adjuster. If the user chooses service, body shop, 
or renter the use case continues at alternate flows (Service, Body shop, or Renter). 

2.1.3 The system will display the following options to the user : 

• Adjuster 

• Service * 

• Body Shop 

• Renter 

• Comment ( The user has th<LQMoiLtQj^^ appear in t hjg_,Rg,seryatio n only/) 

2.1.4 The user elects to create an adjuster callback . 

2.15 The system validates tha t the bill-to name and number is entered. If the bill-to information is 
missing the adjuster callback will be disabled and the use case continues at alternate flow 
(Missing Bill-To). 

2.1.6 The user initiates the system to create an adjuster callback . 

2 - 1 - 7 The system will create an adjuster c allback, based on the crea ted record for the reservation and 
the use case ends. (Note: Once the callback has be en created, the callback can no longer be 
accessed through the reservation process. The callback flag will still appear with a visual 
indicator that the callback exists.! 

2.2 Alternative Flows 

2.3 Service Callback 

2.3.1 The user chooses to create a servic e callback. 

2.3.2 The system will display the following to the user : 

• Adjuster 

• Service 

• Body Shop 

• Renter 

• Comment ("The user has the option to enter a comment that will appear in the Reservation onKO 
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2.3.3 The user elects the service callback , 

2.3.4 The system validates that the service name and number is entered . If the sen/ice information is 
missing the service callback will be disabled and the use case continues at alternate flow 
(Missing Shop). 

2.3.5 The user initiates the system to create a service callback . 

2.3.6 The system will create a service callback, based on the created record for the reservation and 
the use case ends. (Note: Once the callback has been created, the callback can no longer be 
accessed thr ough the reservation process . The callback flag will still appear with a visual 
indicator that the callback exists .) 

2.4 Body shoo Callback 

2.4. 1 The user chooses to create a B ody shop callback. 

2.4.2 The system will display the following to the user : 

Adjuster 
Service 
Bodv Shop 
Renter 

C^mnientjT^ 

t 

2.4.3 The user elects the bodv shoo callback . 

2.4.4 The system validates that the shop na me and number is entered . if the shoo information is 
missing the bodv shop callback will be disabled and the use case continues at alternate flow 
(Missing Shop). 

2.4.5 The user initiates the system to create a body shop callback . 

2.4.6 The system will c reate a bodv s hop callback, based on the created record for the reservation and 
the use case ends. (Note: Once the callback has been created, the callback can no longer be 
accessed through the reservation process. The callback flag will stilLappear with a visual 
indicator that the call back exists.) 

2.5 Renter Callback 

2.5.1 The user chooses to create a renter callback. 

2.5.2 The system will display the following to the user: 

• Adjiister 

• Service 

• Bodv Shop 

• Renter 

• Comment (The user has the option to enter a comment that will appear hi the Reservation only,! 

2.5.3 The user elects the renter callback. 

2.5.4 The system validates that t he renter nam e is entered . If the renter name is missing the renter 
callback will be disabled and the use case continues at alternate flow (Missing Renter). 
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2.5.5 The user initiates the system to create a renter callback . 

2.5.6 The system will create a renter callback, based on the created record for the reservation and the 
use case ends. (Note: Once the cal lback has been created, the callback c an no longer be 
accessed through the reservation process. The cailback fla g will still appear with a visual 
indicator that the callback exists.) 

2.6 Missing Bill-To 

2.6.1 The system disables the adjuster callback and a note is always displ ayed as to why the callback 


O 

iu 
m 

M 

; s 

W 

hi 

ill 

Q 


2.6.2 The user acknowledges the message and the use case continues at 2.1.4 of the basic flow. 
2.7 Missing Sjrag 

back and a note is always displayed as to whv the cailback is 


2.7.1 The system di 
disabled. 

2.7.2 The user acknow ledges the message and the use case continues at 2.3.3 of the alternate flow. 
2.8 Missing Renter 

2.8.1 The system disables the renter callback and a note is always displayed as to why the callback is 
2.8.2 

3. 


The user acknow ledges the message and the use case continues at 2.5.1 of the alternate flow. 
National Reservations 


4. 


5. 


6. 


General Rule Sets 

The user cannot edit or create a c allback for a Natres Reservation . 

ARMS 

A call center or an insurance company creates the ARMS reservation through the ARMS system without a 
callback. The user has the option to create a callback for the reservation, 
Thecaljback creation is treated like any jflfafiUBSfii^^ 

Edit Note 

General Rule Sets 

Deleting a callback cannot be done from t he reservation. 

if the user wants to add a callback once the reservation is c ompleted, the system goes through the same 
validations for edit as it did for create. 
• The callback fla eijQnhLi^^ 

S pecial Requirements-Callback Flag 

General Rule Sets 

1. When viewed through the legacy application, anv of the items that have been checked in the GUI 
application will appear with an "X" for the corres pondin g; value in the legacy application. 

2. The user will have the ability to create a callback record in the same manner as the legacy sygtem creates 
callback records. 

3. Created callbac ks will only be able to be viewed or worked at a callback center or a branch using the legacy 
application. 

4. Callback fla s;s can be accessed during the creation or up date of a r eservation . 

5. The callback flag option must be in view for user dur ing creation of a reservation. 
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7. International Requirements 

• The callback functionality is the same for U.S.. Germany. Ireland. UK and Canada. 

8. Pre-Conditions 

A user has successfully logged onto the computer. 


9. Post-Conditions 

10. Extension Points 

11. Questions 

1 . Is there anything else needed internationally? No 

2. Do we want the system to prompt the user to create a callback on every reservation or make it a 
manual option? We want to force the user to see the option to create a callback when creating a 
reservation. When updating a current reservation, create a callback only needs to be an option. 

3. Should the user have the ability to remove an ARMS/RMS callback? No, only a call center or 
insurance company should be able to remove this callback 

4. Does wording need to be consistent with Legacy or GUI? Leave fields as they are in Legacy. 
(Adj., Body shop, Service, Renter) 


Confidential 


©<Company Name>, 2000 


Page 7 


<Project Name> 

Version: <1.0> 

Use Case Specification: <Use-Case Name> 

Date: <dd/mmm/yy> 

<document identified 


Confidential 


©<Company Name>> 2000 


Page 8 


<Enterprise Rent A Car> 


<Create Reservation 
Use Case Specification: <ECARS 2.0 Reservation> 

Version <1.0> 


<ECARS 2.0 Reservation 

Version: <1.0> 

Use Case Specification: <Create Reservation> 

Date: <05/23/2001> 

<Document identified 


Revision History 



Date 

Version 

Description 

Author 


<5/14/2001> 

<1.0> 

<Initial Draft> 

<J. Gaines> 


5/18/2001 

1.1 

Revisions based on internal review. 
Elimination of first repeat renter search 
screen. 

J. Gaines 


5/22/2001 

1.2 

Revisions based on feedback from user 
review with Jon and Mary: Single match 
no longer populates into renter info screen 
without being selected first. Cancel feature 
is now quit and exit and quit returns to 
Home instead of search screen. 

J. Gaines 


5/23/2001 

1.3 

Doc imported into Req Pro and 
requirements are marked. 

J. Gaines 

IBS' 

m 

9/6/01 

1.4 

Changed wording from Telephone Number 
to Phone Number. 

L. Moellman 




Changed wording from Account Search to 
Search. 


si 

10/10/2001 

1.5 

Removed requirements related to Save and 
Continue functionality 

James Atteberry 


hi 


Confidential 


©<Enterprise Rent A Car>, 2001 


Page 2 


<ECARS 2.0 Reservation 

Version: <1.0> 

Use Case Specification: <Create Reservation> 

Date: <05/23/2001> 

<Document identified 

Table of Contents 



1. Create Reservation 


4 

1 1 Brief Descriction 


A 

2. Flow of Events 


4 

2.1 Basic Flow 


A 

2.2 Alternative Flows 


5 

3 . Special Requirements 



3.1 Edit Requirement 


n 

The data displayed in the populated reservation fields for the repeat renter search is editable. 

n 

3 .2 Saving Requirements. 


12 

3 .3 Fields in the repeat renter file: 


12 

4. Pre-Conditions 


12 

4. 1 The user has successfully logged onto the system. 


12 

5. Post-Conditions 


12 

6. Extension Points 


12 

7. Q's 


12 


Confidential 


©Enterprise Rent A Car>, 200 1 


Page 3 


<ECARS 2.0 Reservation 

Version: <L0> 

Use Case Specification: <Create Reservation> 

Date: <05/23/2001> 

<Document identified 


Use Case Specification: <ECARS 2.0 Reservation> 

1. Create Re servation 
1.1 Brief Description 

This use case describes how a user is presented with options for creating a reservation; the repeat renter 
search, the add new renter and the applicable areas in which to record and save information about the 
reservation with at least the minimum reservation criteria. 

2. Flow of Events 
2.1 Basic Flow 

2.1.1 The user chooses to create a new reservation. 

2.12 The system defaults the iocation to th e Group and Branch numb er where the user logged ]tl 

2.1.3 The system assigns a uni que reservation number to the reservation. (See S pecial Requirements). 

2.1.4 The system displays the following criteria for the user to search on: 

• Last Name ( implied wildca rd search) 

• First Name (first n ame can only be use d as a searc h criteria in conjunction with last name) 

• Phone Number (will search home, w ork, other) g 

• Driver's License Number 

• Date of Birth 

2.15 The system displays the option to add a new renter to this reservation . If the user selects to Add 
New Renter, the use case continues at alternative flow (New Renter). 

2.16 For the basic flow, the user will enter last name and phone number as the search criteria. 

2.17 The user initiates the search. 

2.1.8 The system validates the search criteria entered. If only a last name was entered as the lone 
search criteria, the use case continues at (Last Name Only). If only a date of birth was entered as the 
lone search criteria the use case continues at alternative flow (Date of Birth Only.) 

2.19 The system searches for repeat renters in the repeat renter database, based on the criteria 
entered by the user. 

2.110 The system retrieves all renter n ames and associate d data that is stored fo r that rent er that are 
associated with the search criteria entered. If no matches exist the use case continues at alternative flow 
(No Matches). If multiple matches exist, the use case continues at alternative flow (Multiple Matches), if 
the search takes longer than the prescribed time the use case continues at alternative flow (Quit). If there 
is a do not rent warning attached to the repeat renter profile, the use case continues at alternative flow 
(Renter Warning) 

2.1.11 The system displays the single match retrieved from the repeat renter database. 

The user has the option to do the following: 

• The user selects the repeat renter record match from the list and th e use case continues at 
alternative flow (One Match V 

• Does not select the rep e at renter match from the lis t the use case continues at alternative 
flow (Add New Renter). 

• Quit and th e use case continues at alter nate flow (Quit) . (Note: Not all renter profiles contain 
all data. The system will populate the data it has stored in the repeat renter profile). 
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2.1.111 The renter i nfo fields are po pulated with the information retrieved, for the renter chosen, from 
the repeat renter database. The remaining renter information fields are displayed empty for the user to 
enter new renter information. (A list of available fieids can be seen at 2.2.2.2^ 

2.112 The user has the option to continue the use cas e at the follo wing alternative flows to perform anv 
of the following options or combin ation of options: 

• Add a New Renter fedd renter information). 

• Change Location 

• Add a Pick-up Method 

• Add a Pick-up and/or a Return Date. 

• Add Additio nal Drivers 

• Add a Bill-To 

• Add a Refe rral Source. 

• Add Renter' s Vehicle/S hop Information. 

• Quote Rates 

• Add Insurance Detail 

• Add Cash Qu alification 

• Add Directions 

• Add Notes 

• Create a Callback 

• Print 

2.113 The user has the option to "Complete Reserva tion" or Quit If the user chooses to Quit the 
reservation the use case continues at alternative flow (Quit). 

2.114 The system validates tha t the user has captured the minimum re quired info rmation of Last Name, 
otherwise the use case continues at Alternative Flow (Incomplete Reservation) 

2.115 The system generates and stores the following information: 

• Date and Time of Creation 

• Employee ID of the employee who created the reservation 

(Note: This reservation can be viewed at a later time bv utilizing various areas within the 
system) 

2.116 The use case ends. 
2.2 Alternative Flows 

2.2.1 Change Lo cation (pick UP branch, return branch or both* 

2.2.11 The user is allowed to chance branch location only (for reservation pilot ! within default group. 
(Note: ECARS 2.0 enhancement will allow change of group dependant upon security.) 

2.2.12 The s ystem will display the following information to the user: 

The Pick up and return croup and branch will default to the physical location of the t erminal but will be 
able to be chanced bv the user. When the user selects the dro p down list the syste m will display all of the 
rental branches for the grou p, with the current location highlighted. 

2.2.13 The window will also display the f ollowing information to the user: 

• Branch address 

• Phone number 

• Davs of normal op eration 

• Hours of normal operation 
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This information will b e read only, if a branch is not open a particula r dav the appro priate status will be 
displayed. The branches time zone will be visible as well as an indicator as to if the branch a ccepts after 
hour Pickuos and returns. 

2.2.1 .4 From the basic flow ( ), the user can change location by changing the Group and Branch 
number, or the user can change location by changing just the Branch number by selecting to Change 
GPBR. (See Special Requirements for rules of changing pick up and return branches) 

2.2.1 .5 The use case continues at ( ) in the basic flow. 
2.2.2 Add New Renter 

2.2.2.1 The user chooses to add a new renter reservation. 

IMienter info fields are populated with the current criteria entered in renter search . If there is no search 
criteria entered, there will be nothing populated in t he renter infoJiejds, The remainin g renter information 
fields are displayed empty for the user to enter new renter information: 


Most commonly entered information (North America): 

W o Last Name 

3 o First Name 

o Hm Phone 

0| o Wk Phone 

O o Extension 

H o Other Phone 

W 0 Phone Description 

Most commonly entered information (U.KJ; 

o Last Name 

o First Name 

in o Hm Phone 

n o Wk Phone 

o Extension 


o Other Phone 

o Phone Description 

Less comm only enter ed information (North America!: 

o Address 

o 2e 

o Country 

o fiji}£ 

o State 

o Other Address 

c Employer 

o License Number 

o Expiration Date 

o State Issued 

o DOB (Date of Birth) 

o SSM 

c Height - Fe 

o inches 

o Weight 

o Hair Color 

o Eye Color 
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Primary Payment Method is part of the above iist but will not be implemented until E2 

• Less commonly entere d information (U.K.kAddress (A 2nd renter addr ess field is added in 
ILK] 
c Postal Code 
o Country 


', sis? 


o 

o Other Address 

o Employer 

o Licence Number (note difference in spelling) 

o Expiration D ate Issuing Authority QQfi (Date of Birth) 

o National ID 

o Height - Feet (NOT CAPTURED IN U.K.) 

o Height - Inches (NOT CAPTURED IN U.K.) 

o Weight (NOT CAPTURED IN U.K.) 

o Hair Color (N OT CAPTURED IN U.K.) 

o Eve Color (NOT CAPTURED IN U.K.) 

Npje: Prima ry Payment Method (note: "check'Lis^gjled "cheque") is_par t of the above list but will not be 


flj implemented until E2. Renter has the option of initiating anv o f the following options: 


m 


ill 


Enter data for above listed fields 
Cash Qualification 
Insurance Detail 
Update Repeat Renter 
Direction 
Notes 

(Note: Cash qualification, directions, notes and insurance detail are alternative flows that initiate the Renter use 
case) 

2.2.2.3 User enters renter's last name. 

2.2.2.4 Use case continues at ( ) of the basic flow. 

2.2.3 One Match From the basic flow, the syste m displays the single match under the following 
headers to the user: 

• Renter First and Last Name 

• Street Address 

• Home Phone 

• Office Phone (and extension) 

• Other Phone 

• Date of Birth 

2.2.3.2 The search results are displayed in the following sort order: 

• Alphabetically bv renter's last name. 

2.2.3.3 The user has the option to do the following: 

• The user s elects a repeat renter record from the list and continues at ( ) of the basic flow. 

• Not to select a repeat renter from the list, the use case continues at alternative flow (Add New 
Renter). 

• Search aoain 
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2.2.4 No Match From the basic flow ( ), the system displays a zero result set with a message 
indicating no matches found and the continues at (renter search^ of the basic flow, otherwis e the user has 
the option to add a n ew renter and the use case continues at (Add New Renter!. 

2.2.5 Multiple Matches 

The system retrieves multiple repeat re nter records that have an exact match on the criteria 
entered bv the user 

The system displa ys a list of ail of the repeat renter records that match the inf ormation that was 
input under the Renter Search criteria. The system will make distinguishable anv renter that 
a ppears on the Do Not Rent List If the user selects one of these DNR renters the use case 
continues at Alternative Flow (Renter Warning). The system displays the following information 
to the user: 

• Renter First and Last Name 

• Street Address 

• CM 

• Home Phone 

• Office Phone (and extension^ 

• Other Phone 

• Date of Birth 

The search results are displayed in the following sort order: 

• Alphabeticall y bv renter's last name. 

The user has the option to do the following: 

• The user selects a repeat renter record from the list and continues at ( )of th e basic flow. 

flj • Not to select a repeat renter from the list, the use cas e continues at alternative flow (Add New 

rjj. Rentert. 

j<jj • Search again 

0 2.2.6 Last Name Only 

2.2.6.1 If last name is the only search criter ia entered, the system will prompt the user with an error 

message to en t er additional search criteria and the use case continues at ( ) of the basic flow.. 

2.2.7 Search bv R enter's First Name 

2.2.7.1 The user enters a renter's first name. The system searches for a match on the text, starting from 
the first position i n the field. (There is an implied wildcard at the end of the character se t entered but no 
leading or i mbedded wildc ards within the character sett. (Note: First n ame field is disabled until a valid 
value is entered in the last name fiejdX, 

2.2.8 Date of Birth Only 

2.2.8.1 If date of birt h is the only search criteria entered, the system will prompt the user with an error 
message to enter additio nal search criteria and the use case continues at ( ) of the basic flow. 

2.2.9 QmU 

2.2.9.1 The user uses the quit function to confirm that they do not wish to save anv of the information 
that has been entered for a reservation since the l ast save. 

2.2.9.2 The system prompts the user with a dialog box stating that the reservation will not be saved 
and asking if the user would like to exit the reservation without saving any of the information 


in 


2.2.5.1 


2.2.5.2 


Q 2.2.5.3 


?! 


2.2.5.4 
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2.2.9.3 The use case continues at Reservation Home. 

2.2.10 Incomplete Reservation 

2.2.10.1 The system displays a message notifying that the user has not captured the minimum required 
information necessary (Re nter's Last Name) to crea te a reservation. 

(Note: The user cannot move the message box to the side and attempt to navigate anv area on the 
screen to e nter required information. Thev must click "OK" t o dismiss the message box and enter the 
required information.) 

2.2.11 Renter Warning 

2.2.11.1 The system displays a ren ter-warning window when a renter who is on warning is selected. 
These fields are display only. 

2.2.11.2 The default setting on the window is do not rent. The user can select to override the do not rent 
fry selecting rent. 

• If the user selects do no rent T the system returns the user to Reservation Home. 

• If the user chooses to rent, then the user returns to the reservation ar ea and the renter's 
information is oop ujgted from the repeat renter database into their appropriate reservation fields 
and a system note should be generated and viewable in the n otes area. $ 

2.2.12 Add a Pick u p and Return Pate 

2.2.12.1 The Create Reservation u se case initiates the Renter use case. 

2.2.13 Add Cash Q ualification 

2.2.13.1 The Create Reservation us e case initiates the Renter use case. 

2.2.14 Add Insura nce Detail 

2.2.14.1 The Create Reservation use case initia tes the Renter use case. 

2.2.15 Add a Pick Up Method 

2.2.15.1 The Create Reservation use case initia tes the Renter use case. 

2.2.16 Add Additional Drivers 

2.2.16.1 The Create Reservation use case initiate s the Renter use case. 

2.2.17 Add Notes 

2.2.17.1 The Create Reservation use case initiates the Ren ter use case. 

2.2.18 Add Directions 

2.2.18.1 The Create Reservation use case initiates the Renter use case. 

2.2.19 Add a Bill-To 

2.2.19.1 The Create Reservation use case initiates the Create reservat ion with a Bill-To use case. 

2.2.20 Create a Callback 
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2.2.20.1 The Create Reservation use case initiate s the Create reservation with a Bill-To use case 

2.2.21 Add a Refer ral Source 

2.2.21.1 The Create Reservation use case initiates the Create Reservation with a Referral use case. 

2.2.22 Add Vehicle/Shop Information 

2.2.22.1 The Create Reservation u se case initiates the Referral use case. 

2.2.23 Quote Rates 

2.2.23.1 The Create R eservation use case initiate s the Quote a Rate use case. 

2.2.24 Add Additional Products/Taxes and Surcharges. 
2.2.24.1 The create reservation use case initiates the Taxes use case 

2.2.25 ErM 

2.2.25.1 The create reservation use case initiates the Print use case 

2.2.26 Void 

2.2.26.1 The Create reservation use case initiates the Edit Reservation use case. 

2.2.27 Edit 

2.2.27.1 The Create Reservation use case initiates the Edit Reservation use case. 

2.2.28 Estimate charges 

2.2.28.1 The Create Reservation use case initiates the Perot Pricing Engine use case 

3. Special Requirements for Create Reservation UC 

3.1.1 Requirements for the GUI Reservation number generator are as follows: 

> The first character will be a numeric value and not start with a zero 

> At least one of the characters other th an the first ch aracter must be an alpha 

> Only these values will be used for GUI reservation numbers (BCDFGHJKLMNPQRSTVWXYZ - 
0123456789^ 

> AH letters will be displayed in upper case 

RFNGUTO - Rental GUT Transaction Database Please refer to use case table for requirement 

example. 


Row# 

Unique Key 

GP 

BR 

GUI Reservation 
Number 

ECARS/ARMS 
Reservation 
Number 

1 

123456781 

01 

01 

1B0000 

112233 

2 

123456782 

01 

01 

1C0000 


3 

123456788 

01 

01 

B00000 
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4 

111222333 

01 

01 

123456 

123456 

5 

111122222 

14 

22 

123456 

123456 

6 

222111333 

32 

02 

794568 

794568 


> 

> Row 1 is an example of a reservation initially taken in GUI, sent to ECARS/ARMS. and then updated 
in ECARS. If a reservation is initially taken in G UI r the GUI database will not have the ECARS/ARMS 
reservation number unless it is updated bv the ECARS/ARMS application. 

> Row 2 is an example of a reservation initially taken in GUI and never updated by ECARS/ARMS. 

> Row 3 is an e xam ple of a reservation initially taken at NatRes and brought into Rental GUI through 
Al's API. 

> Row4 t 5, 6 are examples of a reservation initially taken in ECARS/ARMS and then interfaced to 
Rental GUI. The fifth and sixth ro ws depict that all Groups' r eservations will be stored in a single 
database on the GUI application. 

3.2 Edit Requirement 

The data displayed in the populated reservation fields for the repeat renter search is editable. 

if 
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3.3 Saving Requirements. 

The s ystem displays the Saved Reservation confirmation box . If the minimum reservation information 
has not been captured, t he use case continues at Alternative Flow (Incomplet e Reservation^. 

(Note: The Saved Reservation confirmation box confirms to the user that the reservation has been saved 
permanently to the database and that the user has captured the required information necessary to create 
a reservation. No reservation information is saved permanently to the database until a Save is initiated by 
clicking on the "Complete Reservation" button and the minimum required information necessary to create 
a reservation has been captured). 

The system saves the reservation to the database. 

The Saved Reservation confirmation message will be displayed. The message displays the current 
Reservati on number of the rec ord select ed that was saved . The record's information is saved to the 
database and a system note is created capturing: 

3.4 Fields in the repeat renter file: 

• Renter First and Last Name 

• Street Address 

• 

• §!§t§ 

• Zip code/Po stal Code 

• Home Phone 

• Office Phone (and extension) 

• Driver License Number 

• Driver License State 

• Date Of Birth 

• Date Last Rented 

4. Pre-Conditions 

4.1 The user has successfully logged onto the system. 

5. Post-Conditions 

6- System Generated Notes - Create 

6.1 When a reservation is created, the system will gene rate the following note text. "Reservation 


7. Extension Points 

8. Q's 

• Are we allowing the user to update repeat renter information? Yes 

• Do we want the user to be returned to renter search after electing not to rent on a DNR warning? Res 
Home 

• Save and Exit should take the user where? Res Home 

• Zero result set on renter search. Do we want to go to res info screen and populate with search criteria 
entered or do want to search again? Res Home 
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7 
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7 
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Use Case Specification: <Daily Reservation Detail> 


1. Daily Reservation Detail 
1.1 Brief Description 

This use case describes the view of a day's reservations to aid in the daily planning process for 
reservations. The daily activity view is a manually refreshable list of the current day's reservations for a 
group and branch. No-show reservations are no longer displayed by the system in the Daily Reservation 
List and are now displayed in a No-Show list. 

2.1 Basic Flow 

2.1.1 The Reservation Planning use case initiates the Daily Activity use case when the user chooses 
view the Daily Reservation list. The system defaults the location to the Group and Branch Number where 
the user logged in. {If the user changes location, the use case continues at alternate flow (Change 
Location)}. 

2.1.2 The system checks the current date and time and retr ieves the default group/branch reservations 
that have a pickup date equal to th e branch's current local date and all r eservations with no date . If no 
reservations are retrieved, the use case continues at alternate flow (No Records) 

* 

2.1.3 The system displays the Daily Reservation List as the daily activity default . The system displays 
to the user th e results according to th e following headers and so rt order for th e default group and branch 

Column Headers for Daily Reservation List: 

• Time 

• Name 

• Pick up Method 

• Pick up Location 

• Car class 

• Preference 

• Rental Type 

Sort order f or Daily Reservation List: 

• Reservations with a date b ut no time. 

• Reservations with a date and time. 

• Reservations with no dat e but have a time. 

• Reservations with no date and no time. 

Note: Group, Branch and Date are retrieved by the system but not displayed. 

2.1 .4 The system displays the Daily Reservation List to the user so the following is visible and 
highlighted to the user: 

• Reservations with a pick up date and time up to 30 minutes prior to the current date and time. 

• The reservations with a pick up date and time equal to the current date and time. 

2.1.5 The system can be refreshed bv the user and checks the branch's current loc al date and time then 
retrieves a nd dis plays any new reservations* that have a creatio n date eq ual to the branch's current local 
date. These new reservations will display in a manner that make them distinguishable from the other 
reservations already in the list 

*A new reservation is one that: 

• Natres reservations that are sent during the current dav. 
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• ARMS reservations sent during the current riav 

• Branch reservations th at are created during the current for the current dav. 

• Reservation s that are transferred from another branch for the current dav. 

• Reservations that are moved from another dav to the current dav within the same branch. 

• Reservation for the curr ent dav thafs time has been chanced during the current dav. 

2.1.6 . The system checks the current date and time and retrieves the d efault group/b ranch reservations 
that have a Pickup date equal to the branch's current local date and all reservations with no date 

Any reservations with a pickup date of 1 dav thro ugh 5 davs prior to the current dav wi ll be displayed in 
the no-show list. 

These reservations are displayed in the ir appropriate place in the r eservation li st according to the default 
sort order. 

2.17 The user can perform the following op tions: 

• If the user c hooses to print the list, the use case continues at alternate flow (Print the list) 

• If the user elects to print the detail s of a reserv ation from the list, the use case continues at 
alternate flow (Print the reservation details). 

• If the user selects a reservation from the list to edit/view, the use case continues at alternate flow 
(Edit/View a reservation). 

• If the user c hooses to view the rese rvations for a different d ate, the use case continues at 
alternate flow (Chance Date). 

• [f the user chooses to view the reservations for a different location, the use^case continues at 
alternate flow (Change Location) 

• If the user chooses to view the no-sho w reservations, the use case continues at alternate flow 
(View No-Shows) 

Note: User may perform any combination of the above options. 

2. 1 .8 The use case continues at (2. 1 .4) of the basic flow. 


2.2 Alternative Flows 

2.2.1 Reservation Search 

Link 

2.2.1.1 The user elects to search for a reserv ation from the Daily Activity panel. 

2.2.1.2 Initiate Reservation sea rch use case. 

2.2.2 View No-Shows 

Link 

2.2.2.1 The user chooses to view the no show reservations for the default group/branch. 

2.2.2.2 The system will retrieve all daily reservat ions that match the default group/branch for a date and 
time 1 dav through 5 davs prior to the branch's current local date and time. If the system retrieves no 
reservations, the use case continues at alternate flow (No Records). 

2.2.2.3 The system displays a list of reservations acc ording to the Daily Reservation list sort order and 
column headers. The reservations will display in descending date and time order. If the system retrieves 
no reservati ons, the us e case continues at alternate flow (No Records). 

2.2.2.4 Reservati ons that are in the no-show list have been disp la yed there bv the system after 1 
calendar dav has passed after the reservations pickup date. 
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• Date 

• Time 

• Name 

• Pick up Method 

• Pick up Location 

• Car class 

• Preference 

• Rental Type 

Sort order for No-show Reservation List: 

• Reservations with a date b ut no time. 

• Reservations with a date and time. 

• Reservations with no date but have a time. 

• Reservations with no date and no time. 

2.2.2.5 The system removes reservations from the no-show list 6 calendar davs after the reservation 
pick up date. 

2.2.2.6 From within no-show list the user can perfor m the follow ing options: 

• If the user chooses to print the list of no- show reserv ations, the use case continues at alternate 
flow (Print the list) 

• If the user elects to print the details of a no-show reservation from the list, the use case continues 
at alternate flow f Print the res ervation details). * 

• If the user s elects a no- show reserv ation from the list to edit/view, the use case continues at 
alternate flow (Edit/View a reservation! 

2.2.3 Chan ge Location 

2.2.3.1 The user is al lowed to chan ge location to view a branch's daily reservation list 

2.2.4 From the basic flow (2.1.3), the user can change location by changing either the group number or 
the branch number or both. 

2.2.5 The user selects the bran ch drop down list from the detail screen. 

2.2.6 The system will display the rental branche s for the group, defaulting to the current location. 

2.2.7 The user selects a branch from the d rop down list 

2.2.8 The s ystem will display a view of the selected branch 's daily activity for reservations and the use 
case continues at (2.1 .2) of the basic flow. 

2.2.9.1 The user is allowed to chanoe date as far into the future and oast as the system allows, to view a 
daily reservation list. Note: the ability to edit a reservation for another branch is dependant upon 
security. 

2.2.9.2 The use case continues at (2.1.2) of the basic flow. 
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2.2.10 No Records 

2.2.10.1 The system displays a zero results list displa y and the use cas e continues. 

3. Special Requirements - Daily Reservation Detail UC 

1. As in Search Reservation use c ase. Column Headers are sortable. 

2. Types of reservations not shown in the default group/b ranch daily reservation list are as follows: 

• Voided reservations . 

• Reservations transferred to another branch . 

• Reservations that have been attached to an open ticket 

3. When lookin g at lists of reservations, the total nu mber of res ervations for the dav should be 
displayed. 

4. Refresh will be manual refresh. Business does not want refresh to interrupt work in a n application. 
Should not refresh while scrolling through a reservation list. Should not refresh so as to be noticeable 

U bv the user w hile working in an application . 

y 5. Manual refresh of reservation displays - The screen will be refreshed when the user chooses 
Jf: "Refresh". The screen will also refresh after the user leaves and then reenters a reservation display. 

jj 1 a 

ifl 7. In the alternate flow (Pick up Summary screenV from the pick up summary display, the user should 
p be able to click on the time and "hyperlink" to that tim e in the Daily Reservation list. 

M 4. Pre-Conditions 

M 

« 4.1 The user has successfully logged onto the system. 

Is.. 

£I 5. Post-Conditions 

li 

Hf 5.1 < Post-condition One > 

p 6. Extension Points 

6.1 <Name of Extension Point> 
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1 . 1 Brief Description 4 

2.1 The user can enter the reservation for editing from all points of entry into reservation that the 
Navigation Use Case allows 4 

2.2 The system must be able to determine what kind of reservation the user is editing (branch, 

arms, natres, internet) 4 

2.3 The system must be able to determine whether a reservation is for the user's group or from 

another group. 4 

Figure 1: Driver Screen: 5 

3.1 Update 5 

3.1.1 Behavior: Error! Bookmark not defined. 

3 . 1 .2 Business Exceptions: Error! Bookmark not defined. 

3.2 Clear 5 

3.2.1 Behavior: Error! Bookmark not defined. 

3 .2.2 Business Exceptions: Error! Bookmark not defined. 
Figure 3: Referral Screen: 6 
Figure 2: Rates/Dates Screen: 6 

3.3 ARMS 11 
3.3.2 Natres 13 
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5.1 < Post-condition One > 14 
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Use Case Specification: <Edit Branch/ARMS/NATRES 

and Void> 


Edit Branch/ARMS/NATRES and Void 

1.1 Brief Description 

This use case describes the edit process and field behaviors and dependencies when editing a branch 
reservation, an ARMS reservation and a NATRES reservation. Void rules for reservations are also 
included. 

Pre-Conditions 

1 .2 The user can enter the reservation for editing from all points of entry into reservation. 

1 .3 The system is able to determine what kind of reservation the user is editing (branch, arms, natres, 
internet) 

1 .4 The system is able to determine whether a reservation is for the group of the physical terminal 
location or from another group. 
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Figure 1: Driver Screen: 
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Branch Reservation Edit 

1.5 Update 

• Update button will be removed. 

1.6 Clear 

• Clear button will be removed. 

1.7 Driver Fields 

1.7.1 Name: 

• If last name is deleted, the user cannot save the reservation. No edit rules for first name in 
reservation. 

• If the user selects Update and the driver's last name and/or first name is changed, no driver 
associated information fields are cleared. 

1.7.2 Phone Numbers: 

• If Work Number is deleted, the extension will blank out 

• If Other Phone is deleted, type will reset to blank. 

1.7.3 Address: 
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1.7.4 


1.7.5 


No edit rules for deleting or changing address in reservation. 
Driver's License Fields: 

If a driver's license number is added then the state issued, expiration date and DOB fields need 
to be entered as well. 

If a driver's license number is edited, none of the other license fields need to be changed or 
blanked out by the system. 

If any of the four driver's license fields are deleted, the other driver's license information that is 
entered remains, but upon saving the reservation, the system will alert the user to the missing 
piece(s) of driver's license information. 

Primary Payment Method: 

No edit rules exist for changing primary payment method in reservation. 


Figure 2: Referral Screen: 
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1.8 Referral Fields 

1.8.1 Account Name: 

• If account name is changed (to a valid account), account number will change appropriately and 
the contact name will now be "select". 

1 .8.2 Account Number: 

• If account number is changed, the account name will change appropriately and the contact name 
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will now be "select". 
Employee Number: 

There are no edit rules for reservation on changing or deleting an employee number. 
Contact Name 

If contact name is deleted, an error message will be displayed to the user to add a contact name 
upon complete reservation. 
Figure 3: Rates/Dates Screen (Top portion): 
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1.9 Date Fields 

1.9.1 Pick up Date: 

if a pickup date/time already exists in a reservation: 

• If the pick up date is deleted, the pick up time is also blanked. 

• If the pick up date is changed, the new date follows the same rules for entering pickup date. 

• If pick up date is entered and it is after the return date the user will receive an error message that 
pick up date is after the return date and the correction must be made by the user. 

1.9.2 Pick Up Time: 

• If the pickup time is changed, the new time must meet the same rules for entering pickup time. 
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1.9.3 Pickup Method: 

• If the pick up method is changed, the location will remain. 

1.9.4 Return Date: 


If a return date/time already exists in a reservation: 

• If the Return date is deleted, the return time is also blanked. 

• If the return date is changed, the new date follows the same rules for entering return date. 

• If return date is entered and it is before the pick up date, the user will receive an error message 
that return date is before the return date and the correction must be made by the user. 

1.9.5 Return Time: 

• If the return time is changed, the new time must meet the same rules for entering return time. 

1.9.6 Return Method: 

• If the return method is changed, the location will be blanked out 


1.10 Rate Fields 

1.10.1 Account Name 

• If account name is deleted, the account number and rate plan fields will be blanked. 

• If the account name is changed, the same guidelines for entering an account name apply. Must 
choose from dropdown or from search. Once a new account name is chosen, the account 
number will populate and if there is only one rate plan for that account that will populate as well. 
If there is more than one rate plan to choose from the rate plan field will display "select". 

1.10.2 Account Number 

• If account number is deleted, the account name and rate plan fields will be blanked. 

• if the account number is changed, the same guidelines and validations for entering an account 
number apply. Once a new account number is chosen, the account name will populate and if 
there is only one rate plan for that account that will populate as well. If there is more than one 
rate plan to choose from the rate plan field will display "select'. 

1.10.3 Rental Type 

• No business rules for editing Rental type apply in reservation. 

1.10.4 Rate Plan 

• If the user changes the rate plan, "get rates" must be pressed to retrieve the rates for that rate 
plan. 

1.10.5 Car Class 

• If car class is changed, "get rates" must be pressed to retrieve rates for the new car class 
entered. 

• If car class is deleted and the get rates button is pressed the table of rates for the rate 
source/plan entered will be displayed. The user has the ability to select a car class from the 
table. 

• If there was no car class originally entered but there were rates entered and the user selects a 
car class, the rate originally entered will remain unless the user manually types over the rates or 
selects a car class from the table of rates after choosing get rates. 

• Car class may be manually entered with no other rate information. 

1.10.6 Rates 

• Rates May be manually entered without a Rate Source. 
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Rates can be deleted. 

Rates that are edited will remain after the rate source is changed unless a different car class is 
selected from get rates. 

Hitting Cancel after getting rates will keep rates. 


Figure 4: Rates/Dates Screen (Middle Portion): 


'3 FUtcs New - Microsolt Internet Explorer provided by Enterprise Rent-a-Ca 


L,^^- — ~~ ^AI' 


j Y:\APPS\Ecars_20\Developmart r^ojectsVHTMLVRes«v3lion\Rates t l Rates.htaI 




BE5E3 


e 


d 


Reservation : 411781 

rRates 


Rates/Dates 



-Discounts and Specials 
r Add A Special 


1.10.7 Billing Cycle 

• There are no edit business rules associated with this field in reservation. 

1.10.8 CDW 

• There are no edit business rules associated with this field in reservation. 

1.10.9 PAI 

• There are no edit business rules associated with this field in reservation. 


v. 


it 


V. 

Ill 



Figure 5: Rates/Dates Screen (Discounts and Specials): 
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^ Rates New - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 
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| jPerDaySpeael i 
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C Add A Discount 
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1.11 Discounts and Specials 

1.11.1 Add a special 

If add a special is unchecked then start date, start time, end date, end time, special rate and mileage 
remains but the information is ignored by the system. 

1.11.2 Start date 

If start date is changed, the system will validate that the start date is not after the end date. 
If there is a pick up date and the user changes the special start date to a date before the pick up 
date, the system will inform the user that the start date cannot be before the pick up date. 

• If there is no pick up date, and the user changes the special start date to a date before the current 
date, the system will inform the user that the start date cannot be before the current date. 

• If the start date is deleted, the system will display a message that a start date must be specified 
for a special. 

1.11.3 End date 

• If the end date is changed the system will validate that the end date is not before the start date 
and provide a message if it is. 

• If there is a return date, then the special end date cannot be after the return date, otherwise the 
system will display a message that the special end date must be equal to or before the return 
date entered, 

• If the end date is deleted, the system will display a message that an end date must be specified 
for a special. 
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111.4 Start Time 

• No business rule for deleting the start time of a special. 


1.11.5 End time 

• No business rule for deleting the end time of a special. 

1.11.6 Rate 

• No business rule for deleting the rate on a special. 

1.11.7 Type 

• There is no validation on changing the type. 

1.11.8 Mileage 

• There is no validation on changing or deleting the mileage for a special. 

1.119 Mileage Type 

• There is no validation on changing the mileage type. 

11110 No charge 

• If there is a mileage charge on the reservation there must be a mileage charge for the special. 

• If there is no mileage charge on the reservation there can't be a mileage charge on the special. 

111.11 Add a discount , 

• If the add a discount box is unchecked when editing, the discount percent remains but is ignored 
by the system. 

• If the discount box is checked when editing, a discount must be entered. 

11112 Discount Percent 

• The discount amount can't be changed to over 50% or less than 1%, otherwise the system will 
inform the user as such. (Discounts must be entered in whole numbers). 


1.12 ARMS 

112.1 Protected Fields in ARMS 

• If the reservation originated from the ARMS system there are certain fields that will be 
protected/(not editable by the user). They are as follows: 


1. 

Claim/POL/PO Number 

2. 

Claim Type (C,I,T) 

3. 

Insured's Name 

4. 

AuthBy 

5. 

Direct Bill (Y,N) 

6. 

% Auth 

7. 

Max Days Authorized 

8. 

Max Billable Amount 

9. 

Policy Max Amount 

10. 

Daily Max Amount 

11. 

Date of Loss 

12. 

Bill-To Start Date 
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13. Bill-To End Date (Auth until Date) 

14. Number of Days Authorized 

15. Daily Rate Authorized 

16. Tax Authorized (Y, N) 

17. Car class Authorized 

1 8. Cancellation Date (Last Day Date) 

19. Bill-To Account Number (Except if root only is entered then protected once fiill account 
number is entered) 


1.12.1.1 Editable Fields in ARMS: 

(Note: The following editable fields for ARMS reservations follow the same edit rules as the non-arms 
reservations that were covered above in Driver) 

• Driver Last Name 

• Driver First Name 

• Hm Phone 

• Work Phone 

• Extension # 

• Other Phone 

• Phone Description 

• Driver's Address 

• Zip 

• County 

• City 

• State 

• Other Address 

• Employer 

• License Number 

• Expiration Date 

• State Issued 

• DOB 

• SSN 

• Height 

• Weight 

• Hair Color 

• Eye Color 
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1.12.2 ARMS indicator 


• Once a user selects an ARMS reservation for editing, the system must know the status of 
the reservation; contacted, contact attempted or not contacted. 

• Before the user will be able to save or exit the reservation, the system will display a 
message to the user that must be responded to: 

1 . Has the renter has been contacted? Yes and No check box or option areas will be 
displayed. 

2. Has an attempt been made to contact the renter? Yes and No check box or option 
areas will be displayed. 

• If the ARMS reservation that's being edited is in a not contacted state and the user 
saves, the user responds that contact was attempted and the status of this reservation 
will change to contact attempted. 

• If the ARMS reservation that's being edited is in a not contacted state and the user 
saves, the user responds that contact was made and the status of this reservation will 
change to contacted and this reservation will no longer display in the ARMS notification 
result list 

• If the ARMS reservation that's being edited is in a contact attempted state and the user 
saves, the user responds that contact was attempted and the status of this reservation 
will not change. 

• If the ARMS reservation that's being edited is in a contact attempted state and the user 
saves, the user responds that contact was made, the status of this reservation will 
change to contacted and will no longer display in the ARMS notification result list. 

• If the ARMS reservation that's being edited is in a contacted state and the user saves, no 
message will be saved. 


1.13 NATRES 

1 .13.1 .1 Protected Fields in Natres 

• A Branch employee cannot edit a National Reservation originated reservation. If a 
National Reservation is selected for editing by a branch employee, all fields for the 
Reservation are view only. 

• (See Enhancement #1 080 - Ability to Edit Natres Reservations). 

1.14 Completing after Editing information 

• Saving an edited reservation follows the same business rules as saving a created 
reservation and the same validations occur and informational messages and error 
messages will display upon committing the edited information to the database. 

1.15 Void 

1 . ARMS and NATRES reservations may not be voided by branch personnel. 

2. An outside group cannot void branch reservations for a group other than the owning group of the 
physical terminal signed onto by the user. 
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3. For branch reservations, void must be available to the user on all reservation screens. 

4. The system must confirm to the user that a reservation is being voided. 

Special Edit Rules 
Post-Conditions 

1.16 < Post-condition One > 

Extension Points 

1.17 <Name of Extension Point> 
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Alternate Flows: No Match to 
Zip/Postal Code, Multiple City 
Results, Missing Name Information 
and Invalid Characters. 

4. Added the following fields: 
insurance Company Name, Agent's 
Name, Agent's Phone Number and 
Policy Number. 

5. Password and Employee Name is 
oniy requireo wnen emenng oasn 
Qualification Information during the 
Ticket orocess 

o. Take out Supervisors Phone 
Number (Todd Shvlanski 6/13/01) 


-06/2 1/2001 

i E 

1 5 

1 Removed the foilnwinn fields* 

David Rpphe 



Insurance flnmnflnv Name Anent'^ 


; y 


Name, Agent's Phone Number and 


135 


Policy Number 




2. Added (Blank) as an option for the 

0 



luiiowiny iieius. 




Ownership 




Rented Previously 




Do You Own a Car? 


il/7/01 

y, 

1.6 

Changed wording from Telephone 
Number to Phone Number. 
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Use Case Specification: Enter Cash Qualification 

Information 

1. Enter Cash Qualification Information Use Case 

1.1 Brief Description 

This use case will describe how the user and the system interact to input cash qualification 
information concerning renters and/or additional drivers. It will show the flow of events that 
occur when information is input and/or selected in this area. 

2. Flow of Events 

2.1 Basic Flow 

2. 1. 1 Cash Qualification Information Area 

The Enter Ca sh Qualifica tion Information Use Case begins when the system displays the area 
for entry and selection of information about the person being cash qualified and the rental. JM 
fields in this area are: 

• How Long at the current address: 
o Years 

o Months * 

• Ownership: 
o (Blank) 
o Own 

o Rent 

• Current Employer 

• Position 

• Superviso r's Name 

• Spoke to Whom 

• How Lon g at Current Job: 
o Years 

o Months 

• Reason for Renting 
o Car In Shoo 

o Weekend 

o Vacation 

o Other 

o Other Reason Field 

• Previously Rented: 

o (Blanks 
o ¥§§ 

o mq 

o If So. When? 
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• Do You Own a Car?: 
o (Blank) 

o Y§§ 
o Mq 

• Reference #1 

o First Name 

o Last Name 

o Phone Number 

o Relationship 

• Reference #2 
o First Name 
o Last Name 

o Phone Number 
o Relationship 

• Reference #3 

o First Name 
o Last Name 

o Relationship 

• Password 

• Employee Number 

There are no default values for any of the above fields. 


2.1.2 Option to Cancel 

The system d isplays the option for the user to cancel/exit . At any point during the entry of cash 
qu alification information th e user could decide to canc el out of the entry process at which time 
case would continue at 


2.1.3 Option to Save 

The system displays the option to Save. At any point during the entry of cash qualification 
information the user could decide to Save, at which time the use case would continue at basic 
flow Save. 


2. 1.4 Address and Ownership Information Selection 

The user can select how long the person being cash qualified has lived at the current address 
The user can a lso select whether the person being ca sh qualified owns or rents. 
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2. 1 . 5 Employment Information Entry and Selection 

• The user can enter the employment inform ation about the person being cash qualified. 
Thev can enter the employer, the su pervisor's name, the person being cash qualified 
em ployment position and whom the user spoke to when verifying. 

• The user can also select how long the person being cash qualified has been employed at 
their current lob. 

216 Rental Information Entry/Selection 

• The user c an select one or more reasons for renting . If the user selects the "other" 
option, the fi eld for entry o f information becomes available for entry. The user then enters 
the reason. 

• The user can select wheth er the perso n being cash qualified has rented before. If the user 
selects "Yes", the field for entry of infor mation about when thev last rented becomes 
available. The user then enters when the last rental was. (See Special Requirements for 
note.) 

• The user can select whether the person being cas h qualified owns a car. 

• The user can enter the insurance company name , agent 8 s name, agent's phone number 
and the policy number information about the person being cash qualified. 

2. 1 7 References Information Entry 

For all three references listed, the user can enter the First Name. Last Name. Phone Number 
and Relationship. 

218 "Approved by:" Employee Number and Password Entry 

The user en ters the Employee Number and password that approved the cash qualification. 

2.1.9 Select Save Option 

The user selects the option to Save. 

2 1 1 0 Validation of Employee Number and Password 

The system validates t he Employee Number and password that approved the cash 
qualification. If the user entered an invalid employee number and password combination the 
use case continues at alternate flow Invalid Employee Number and Passw ord Combination. If 
the user entered an employee number and password that does not pass authority check the 
use case continues at alternate flow Authority Check Failed . 

2.1.11 Save 

The system s aves all th e information entered or s elected in the fields of the Cash Qualification. 
The saved information would include the following: 

• How Long at the current address: 
o Years 

o Months 

• Ownership: 
c (Blanks 
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o Own 
o Rent 


• Current Employer 

• Position 

• Supervisor's Name 

• Spoke to Whom 

• How Long a t Current Job: 
o Years 

o Months 

• Reason for Renting 
o Car in Shoo 

o Weekend 

o Vacation 

o Other 

o Other Reason Field 

• Previously Rented: 

o (Blanks 

o Y§§ 

o Nfl 

o If So. When? * 

• Do You Own a Car?: 
o (Blanks 

o Y§§ 
o HQ 

• Reference #1 

o First Name 

o Last Name 

o Phone Number 

o Relationship 

• Reference #2 
o First Name 
o Last Name 

o Phone Number 
c Relationship 

• Reference #3 
o First Name 
c Last Name 

o Phone Number 
o Relationship 

• The employee who selected to save the cash qua lification information 

2.1.12 End 

The Use Case ends. 
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2.2 Alternative Flows 

2.2.7 Cancel/ Exit 

2.2.1 .1 The user selects the option to cancel/exit. 

2.2.1.2 The system displays a feed back message warning that the cash qualification data will be iost if 
the user selects to cancel/exit. 

2.2.1.3 The system displays the following options: 

* Yes: to exit and lose data. 

• No: return to the cash qualificatio n use case. 

(The default option will be No: return to cash qualification.^ 

2.2. 1 .4 The user selects Yes the use case ends. If the user selects No then continue in basic flow at 
the point where the user selected to cancel/exit. 

2. 2. 2 Invalid Employee Number and Password Combination 

2.2.2.1 The system displays a feedback message that the entered Employee Number and password is 
invalid. 

2.2.2.2 The system prompts the user to enter a valid Employee Number/password. 

2.2.2.3 The user selects to enter a valid Employee Number/password and returns to "Approved by" 
Employee Number and Password Entry . 

2.2.3 Authority Check Failed 

2.2.3.1 The system displays a feedback message that the employee is not allowed to authorize cash 
qualification. 

2.2.3.2 The system prompts the user to enter a valid Employee Number/password. 

2.2.3.3 The user selects to enter a valid Employee Number/password and returns to "Approved by" 
Employee Number and Password Entry . 


3. Special Requirements for Renter Cash Qualification information 

"Do You Own a Car Text Fields 

These fields coul d be left blank: there is no va lidation to make sure information was entered. 
Previously Rented Text Field 

The user can enter whatever thev want to, Thev could enter things like "Last summer". "A few 
months a go". They could als o enter date information li ke "April 20QQ" nr a more formal date like 
"04/94/2001 ». The field could als o he left blank: t here is no validation to make sure information 
was entered. 

Password and Employee Number 

The system requires password and employee number verification when cash qualification 
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information is entered during the open ticket process. The system will not require password and 
employee number verification during the reservation process. 


4. Pre-Conditions 

A user is already authorized through a login process to access the panel that is necessary to: 

• Create or edit a reservation. 

• Open, edit or close a rental ticket. 

5. Post-Conditions 

6. Extension Points 

7. Questions 

Question: How should the Employee Number Approval field work? Should this field be: 

1 Automatically populated (and display only) based upon the user that is currently logged on 

and opening the ticket? (This assumes person opening ticket is also doing the cash 

qualification.) 

2. Automatically populated based upon the user that is currently logged on and opening the 
ticket but able to be changed? (This assumes person opening ticket is also doing the cash 
qualification but also allow changes.) 

3. Blank upon initial entry and allow entry of any employee (valid) number? (No assumptions 
about who is doing the cash qualification.) 

4. Blank upon initial entry and have security to authorize employee number? (This way a 
manager could "authorize" a cash qualification with security.) 

Answer: Since Cash Qualification information is a serious matter, the input from Jon and Mary 
is that the last choice is what they wanted. The user will need to enter a valid employee number 
and update code combination. However this will only be required for an open ticket. 


Question: What European requirements are there? 

Answer: Jon Jouris has indicated there could be translations for the U.K., Germany etc. Fields 
could be eliminated or labels could changed. 

As of 06/01/2001: once the feedback from the review has been integrated, an electronic copy of 
this document will be forwarded to the proper parties for European requirements and 
translations. 
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Revision History 


Date 

Version 

Description 

Author 

05/21/2001 

1.0 

Initial Draft 

David Beebe 

06/01/2001 

1.1 

Revisions based upon feed back from 
user review with Jon and Mary. 

1 . Employee Number is no longer an 
entry field: the system populates this 
field based uoon the user in the active 
session. 

2. OK/Exit renamed to "Save" 

3. Selection of the Save option does 
not provide a feedback message to 
make sure they want to do that. 

4. Moved validation of date to after 
the "Save" step. (In HTML, Date 
Validation occurs after form submittal.) 

David Beebe 

06/26/2001 

1.2 

Added (Blank) as an option for the 
following fields: 

• Liability 

• Assigned Risk 

• Lienholder Policy 

Dave Beebe 

06/28/2001 

• 

1.3 

Revisions to match the Screen Action 
Spec document. 

1 . Removed the employee number 
gathered insurance information 
field. 

2. Moved the insurance company 
employee indi vcjiiicu hiouicshuc 
information field. 

^ Qwitr»h*arl nrriezr nf f*f\mnrAhpri^i\/^ 
O. OWilwilcU UiUCfl vsi wUiUJJi ci lei lOivc 

Deductible and Collision Deductible 
fields. 

4. Removed Special Requirement that 
Employee Number field is available 
for edit 

David Beebe 

9/7/01 

1.4 

Changed wording from Telephone 
Number to Phone Number. 

L. Moellman 

10/26/01 

1.5 

Revised to match Screen: 

Deleted option to Save and Cancel. 

Reworded option to Exit to match 
screen and added an option Complete. 

L Moellman 
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Use Case Specification: Enter Renter's/Additional 
Driver's Insurance Information 


1. Enter Renter's/Additional Driver's Insurance Information Use Case 

1 .1 Brief Description 

This use case will describe the interaction that occurs between a user and the system when the 
user inputs and selects details pertaining to the insurance information about a person who is a 
renter or additional driver. 

2. Flow of Events 

2.1 Basic Flow 

2. 1. 1 Insurance Detail Area 

The Enter Renter's/Additional Driver's Insurance information Use Case begins when the 
system displays the area for entry and selection of insurance information about the person who 
is a renter or additional driver The fields in this area are: 

Information about the insu rance Company 

• Carrier * 

• Agent 

• Phone Number 

• Name of Insurance Company Contact 

• Policy Num ber 

• Expiration Date 

Information about the renter's or the additional driver's insurance 

• Comprehen sive Deductib le 

• Collision Deductible 

• Liability? 
o (Blank) 
o Y§§ 

o Mg 

• Assigned Risk? 

o Yes 

o 

• Lienholder Policy? 
c (Blank) 

o Y§§ 

o jvis 


2.12 Option to Exit 

The user has the option Exit the panel. At any point during the entry of insurance information 
the user coul d decide to e xit out of the entry process at which time the use case would continue 
at alternate flow Exit. 
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2. 13 Company and Insurance Detail Information Area Entry 

The user ca n enter inform ation in the following fields: the name of the Carrier, the name of the 
Agent, Phone Number. Insurance Company Contact, Pol icy Numbe r, Expiration Date, the 
Collision D eductible am ount and the Compr ehensive Deductible amount The user ca n also 
s elect the available choices for Liability, Assigned Ri sk, and Uph older Policy. There are no 
default values for anv of the above fields. 

2. 1 4 Select Complete Option 

The user selects the option to Complete the reservation. 

215 Validation of Date 

The system validates th e value in the Expiration Date field. If the Date value is not valid 
because it does not exist (for example 02/30/02) the use case continues at alternate flow 
Invalid Date . If the Date value is not valid because the Expiration Date is prior to current date 
the use case continues at alternate flow Expired Policy Date . 

2.1.6 Validation of Information Entry 

The system validates that if information is entered in anv one of the following fields, that ail of 
the other fields listed a lso have info rmation entered in them: 

• Carrier 

• Insurance Company, Contact * 

• Policy Number 

• Expiration Date 

• Collision Deductible 

• Comprehensive Deductible 

• Liability: Yes/No 

if the system determines that any of the above fields are missing information, the system will 
present the user with a f eedback me ssage as to what fields are not filled to complete 
insurance I nformation The system will display the option for the user to proceed back to 
Company a nd Insurance Detail Inf ormation Area Entry in the basic flow to complete entry. 

2.17 Complete 

The user selects to conaulete the reservation . 

The system saves all the information e ntered and selected in the fields of the of this use case 
flow and completes the reservation . This would be: 

• Carrier 

• Agent 

• Phone Numb er 

• Insurance Co mpany Contact 

• Policy Number 

• Expiration Date 

• Comprehensive Deductible 

• Collision De ductible 

• Liability?: (Blank). Yes. No 

• Assigned Risk?: (Blan klYes, No 

• Lienholder Policy?: fBlankVY es. No 
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2.18 End 

The Use Case ends. 


2.2 Alternative Plows 

2.2.1 jBdf 

2.2.1 . 1 The user selects to Exit the additional driver information panel. 

2.2.1.2 The system displays a message t hat asks you if vou want to save the reservation before 
exiting. 

2.2.2 Invalid Date 

2.2.2.1 The system displays a f eedback me ssage that the Date is invalid. 

2.2.2.2 The system prompts the user to correct the Date that is invalid. 

2.2.2.3 The user selects to correct the Date and the use case proceeds back to Company and 
Insurance Detail Information Area Entry in the basic flow. 

2.2.3 Expired Policy Date 

2.2.3.1 Ih^stem^splays a feedback message t hat the policy has expired. * 

2.2.3.2 The system prompts the user to : 

• Correct the policy e xpiration date. 

• Exit the Insurance Information Entry process. 

2.2.3.3 If the user selects to change the expiration date the use case proceeds back to Company and 
Insurance Detail Information Area Entry in the basic flow. If the user selects to exit the open 
ticket process the use case continues at alternate flow Cancel / Exit 

3. Special Requirements - Enter Renter's/Additional Driver Insurance 
Information. 

4. Pre-Conditions 

A user is already authorized through a login process to access the panel that is necessary to; 

• Create or edit a reservation. 

• Open, edit or close a rental ticket. 

5. Post-Conditions 

6. Extension Points 

7. Questions 

Question: In the Employee Approval of the Renter's Insurance Information area should there 
be further security? (for example: update code). Or can the user just input the employee 
number and have the system save it as long as it is a valid employee? 
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Answer: No further security is needed. The employee number information will be automatically 
populated into the correct field. This field is display only and the information in it cannot be 
changed. 


Question: What European requirements are there? 

Answer: Jon Jouris has indicated there could be translations for the U.K., Germany etc. Fields 
could be eliminated or labels could changed. 

As of 06/06/2001 an electronic copy of this document had been sent to Jon Jouris so that he 
can pass it on to the appropriate European personnel for feedback. 
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Revision History 


Date 

Version 

Description 

Author 

6/14/01 

1.0 

Initial Draft 

M. Pallia 

6/25/01 

1.1 

First Draft 

D. Beebe 

6/27/01 

1.2 

Revisions after meeting and getting 
feedback from Maribeth, Mike P. and 
Jackie L. 

Changes are: 

• Rewriting for clarification. 

• Restated Brief Description. 

• Explained that Notes is accessed 
via a reservation or ticket. 

• Added detail to "Notes Summary" 

• Pulled sort orders and defaults 
from Special Requirements and 
back into document. 

• Added Questions to be asked of 
the business. 

D. Beebe 

ft 

06/28/01 

1.3 

Revisions after feedback in meeting 
with Marty Tichy. 

Changes are: 

• Date and Time combined since 
they are saved in the Notes 
database as one field. 

• Multiple users should be able to 
view the same note or notes. 
However only one at a time can 
edit. (This is application wide 
standard and does not belong in 
use case.) 

This is the version sent to Mary and 
Jon for the User Review on 7/2 

David Beebe 
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7/5/01 

1.4 

Revisions based upon feedback from 
Mary and Jon. Changes are: 

• Add Status (Reservation, Open and 
Close) to Summary 

• Change available Note Types to 
System, Callback and Internet 
Shop. Shop, Bill-To and Renter will 
be available in a later 
enhancement 

• Removed from Add Note Sub Flow 
the ability for the user to select the 
Note Type. All Notes currently 
added will be "Callback" type. 

• Added the ability to Print a 
particular note or the entire 
summary list 

David Beebe 

9/4/01 

1.5 

Updated use case so that it matches 
the version in the Open Ticket 
repository. 

• Updated Note Types 

• Added info to supplemental 
requirements that indicate what 
date and time display when viewing 
a saved note. 

David Beebe 

9/5/01 

16 

Changed default value from "Callbacks" 
to "Manual". 

David Beebe 

11/9/01 

1.7 

Removed all requirements for "Print 
Current Page." 

David Beebe 

11/28/01 

1.8 

Updated list of Note Types 

David Beebe 
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Use Case Specification: Notes 

1. Notes Use Case 

1.1 Brief Description 

This use case describes how the user interacts with the system to view all notes associated to a 
ticket or reservation, select to view certain types of notes, add a new note or view the full details 
of a previously entered note. 


2. Flow of Events 

2.1 Basic Flow 

2.1.1 Selection t o View Notes 

The Notes Use Case begins when the user navigates to the N otes area of a reservation or ticket. 
This could take place at anv point in the reservation and ticket p rocess. (Notes can be viewed at 
anv point in the ticket process: when creatin g a reservation, e diting the reservation, opening a 
ticket using the reservation, editing the op en ticket, closing the ticket and after the ticket is closed 
Notes will carry forward from a reservation to a ticket when a ticket is opened using the 
flj reservation.) 

m 

O 2. 1.2 System Search esJoiNotes t 

3 1 The s ystem searches for and retriev es all notes a ssociated to the reservation or ticket . 

(»l 2.1.3 System Displays Notes Summary 

HI The system displays the notes to the user in a summary list. On initial entry to the Notes 

111 Summary List the system will display all notes, regardless of type, sorted from the newest to the 

CP oldest by date and time. The columns displayed to the user are the following; 


0 


Date and Time (when the note was saved) 

Note 

Status 

o Reservation 
o Open 
o Close 
Note Tvoe 
o M 
o Bill To 
o Callback 
o Manual 
o Renter 
o Reservation 
o 
o 

Crested Bv 

ARMS mes sage status: 
o (Blank) 
o Sent 
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2.14 Option to Add Note. View Note Deta il Print Not es and change displayed Note Types 

The system displays the options to select to: 

• Add a new not e to the reservation or ticket 

* View a sing le note th at had been previousl y entered. 

* Print (either the Current Page or Ail Notes 1 ) 

• View notes o f a particular Type 

2.15 Add Note. View Note Detail and View Summary Based Upon Note Type Subfiows 

Depending on user preference, he or she will use one of the following three sub-flows: A dd Note. 
View Note Detail an d View Summary Based Upon Note Type . More commonly, the Add Note 
Sub-flow is used. If the user selects to print all Notes (regardless of Note Type and Status) the 
us&case continues at alternate flow Print AH Records, 


2.2 Add Note Subflow 

Q2.2.1 Select to Add Note 

O The user selects to add a Note to the reservation or ticket. (A Note call n be added at any pointjn 

m 


the ticket process: when creating a reservation, editing the reservation, opening a ticket using the 
reservation, editing the open ticket, clo sin g the tick et and after the ticket is closed.) 


M2.2.2 Add Note I nformation Area 

W The system displays the a rea for the user to enter the Note. (Enhancement proposed for the 

; ! future: S ystem also displays the area for the user to select the Note Type. The possible Note 

|«* Types are: Shoo. Bill-To and Renter.) 

ni 

{1J2.2.3 Potion to Sa ve and Potion to Cancel 

Q1 The system displays th e option to: 
• Save 


• Print All Records 

At any point during the Add Note process the user c ould decid e to exit at wh ich time the use case 
would continue at alternate flow Cancel. (If the user cancels without making an entry, no 
feedback messa ge will be displayed.) 

2.2.4 User Entr y of Note 

The user enters the note. 

2.2.5 User Selects Potion to Save 
The user selects to Save. 

2.2.6 Validation Note was entered 

The s ystem validates that a note has b een entered. If the system determines a no te was n6t 
entered, the use case will continue at alternate flow No Note. 

2. 2. 7 Save Add Note information 

The system saves the note. This system also saves information from the following areas: 

• Date and Time 

• Note 
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• Note Type of u Manual" 

• Created By 

The user will not be able to select the Note Type, date & time. Status and the "Created By" party. 
These item s are determined and populated b v the system. (As stated above, future proposed 
enhancements will allow the user to select the Note Type.) 


2.2.8 End 

The system closes the Add Note area and the use case ends. 


2.3 View Note Detail Subflow 

2.3.1 Select to View Note 

The user selects to view the details of a single, previously entered note within the summary list of 
notes for the selected reservation or ticket. 

2.3.2 View Note D etail Area 

The system displ ays the Note Detail showing: 

• Date and Time 

• Note # 

• Note Type 

• Created Bv 

• &RMS message status : 

2.3.3 Option to C lose View No te Area 

The system displays the option to close the area that displays the details of a particular note. JM 
system also displays the options to print the current Note. 

2.3.4 User Selects Option to Close the. View ed Note 

The user selects to close the View Note Detail area. If the user selects to print the current Note 
the use case continues at alternate flow Pfmt Note. 

2.3.5 End 

The system clos es the View N ote Detail area and the use case ends. 


2.4 View Summary Based Up on Note Type Subflow 

2.4. 1 Select to View Summary Based Upon Note Type 

The user selects t o the view note s summary of a certain note type. 

2.4.2 Display Possible Note Types and Ticket Status to sort from 

The system displays the list of possible Note Types to select to sort from: 

• M 

• .System 

(Future Proposed Enhancements will allow the user to select to also sort from Shop. Bill-To and 
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The system displays the list of possih le Ticket Stat us to Sort From 

• AH 

• Reservation 

• Open 

• Close 


2.4.3 Options to Print 

The system displays the option to: 

• Print All Notes 

2. 4. 4 User Selects Note Type 

The user selects a Note Type they want to view. 

2. 4. 5 System Searches for Notes 

IM-system searches for and retrieve^nQteajtssocjated to the tic ket or reservation . 

2. 4. 6 System Displays Notes Summary 

The system displays the no tes to the user in a summary list. The columns displayed to the user 
are the following: 

• Dateajid Time 

• nm 

• Note Type: bgsgd upon the type the user selected 

• Crested By 

• ARMS message status 

2.4.7 Print 

If the user selects to print all Notes (regardless of the currently displayed Note Type) the use case 
continues at alternate flow Print All Notes . 

2.4.8 End 

The use case ends. 


2.5 Alternative Flows 

2.5.1 No Note 

2.5.1.1 The system displays a feedback message: "Please enter a Note if select ino to Save." 

2.5.1.2 The user has the option to: 

• Exit the Add Note process 

2.5.1.3 If the user s elects to enter the note, use case proceeds to User Entry of Note in the Sub Flow 
"Add Note", jf the user selects to exit the Add Note process the use case ends. 
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2.5.2 Cancel 

2.5.2.1 The system displays a feedback message: "Are vou sure vou want to exit and lose the entered 
information?" 

2.5.2.2 The user has the options: 

• Yes (exit and lose the information^ 

• No (return to the use case at the point where the user selected to exit from.) 
The default option will be "No". 

2.5.2.3 If the user selects to exit the Add Note process, the use case proceeds to System Displays Notes 
Summary in the Basic Flow . If the user selec ts No. the use case proceeds to User Entry of Note 
in the Add Note Subflow. 

2.5.3 Print All Notes 

2.5.3.2 The use cas e returns to the point wher e the user initiated the print function. 

2.5.4 Print Note 

2.5.4.1 The system initiates the Print Use Case . * 

2.5.4.2 The use case returns to t he point whe re the user initiated the print function. 

3. Special Requirements for Notes 

• Previously entered notes mav not be edited or deleted bv the user. 

• ystem generated and m anuall y entered) will be displayed ba sed upon the date and time of 
the physical terminal locatio n of the user viewing the notes. 

4. Pre-Conditions 

• A user is authorized through a login process to create or edit a reservation or ticket. 

• The user has accessed a reservation or ticket, either in the process of editing or creating. 

5. Post-Conditions 

6. Questions 
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Use Case Specification: <Quote a Rate> 


1- Quote a Rate 

1.1 Brief Description 

This use case will describe how a user interacts with the system to search for and retrieve a 
single rate or set of rates for a source, using the following Dates/Rates search criteria; rate 
source, rental type, rate type and car class. It will show the flow of events that occur when a 
search is conducted to locate a rate or set of rates. The system will search for and locate a rate 
or set of rates based on the dates/rates criteria entered by a user using an ECARS 10 wrapper. 
This use case doesn't describe quoting rates using the new VRS from Perot. 

2- Flow of Events 
2.1 Basic Flow 

2. 1 . 1 The use case begins when the user chooses to quote a rate. 

2.1.2 The system determines the pick up Group and Branch and the pick-up date and time for the 
reservation. If the Group and Branch is a Europ ean location, the use case continues at (UK f Ireland 
Germany SubflowV If the Group is within a state that has VLF , the use case continues at alternate (VLF 
Ranges). $ 

2.1.3 The system displays all dates/rates criteria fields, allowing the user to enter specific search criteria 
as can be seen in Table A. Differences, by country, can be seen in tables B y QJDJL 

Table A 

BASELINE S ET OF REQUIREMENTS! 

Dates/Rat es criteria required to quote a set of rates: 

• Pick-Up Branch (defaults to terminal^ group 
and branch) 

• Ejck-IJa,Da.teadefaults to cun-eni^tejfnp^Lck 
up date is entered. 

• Rate Source (drop down of valid domain 
values') or 

• Accrjunt Nu mber (text entry box). 

• Rate Plan (i.e. Internal, warranty, cs pay, etc... 
from SI) 

Additional optional criteria to quote rate: 

• Return Date (defaults to one calendar dav after 
pick up date if n o date is entered) (Note: 

rales) 

• VLF Ranges 

• Vehicle Preferences 

• Billing Type 

• Rental Type 

(Note: The user mav type within th e Customer Name. 

Rates, and (Branch Ra tes) Rate Tvo e or select from a 
liSL 
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Table B: 

US and Canadian Differences to Baseline 
Requirements: 


Car class (v alid bv car class for Rate Source! 

Or 

View Table of rates, (rates for ALL valid car classes for a 


2.14 The user enters a pick-up d ate (this mav have already been entered) and a rate source . If a car 
class is manually entered, the use case continues at alternative flow (Select a Car Class). 

2.1.5 If no pick up date is entered, the system uses a default date of the current date. 

2.1.6 The system p opulates the R ate Source field with value s from the follo wing croups: anv selected 
Bill To customers, anv selected Referral customers, anv selected Shoo customers, followed by the branch 
short list and branch defaults . The branch short list and branch sta ndard rate sources will b e combined 
but placed in alphabetical order. If the pickup branch is a utilization management branch the system will 
add "Utilization Management' as an additional group to use as a rate source. (See Special 
Requirements) 

t 

2.1.7 The user selects the Rate Source bv en tering the Customer Number in the Cust omer Number text 
entry field. If the user enters the Account name, the use case continues at alternative flow (Account 
Name). If the user selects from the branch short list, the use case continues at (Branch Short List). If the 
user selects Standard Rates, the use case continues at alternative flow (Standard Rates). If the user 
chooses to view the VLF ranges, the use case continues at alternate (VLF Ranges). If the user decides 
to select a billing cycle, the use case continues at alternate (Billing Cycle) 

2.1.8 The non-seiected rate source field is pop ula ted with the appropriate value by the system . For 
example if the user en ters the Cu stomer Number, the system displays the matching custom er name in the 
Account Name field. If the Account Name is selected a list, that Customer Number is po pulated in the 
Customer Number field. (Note: The user may also select any other customer as the Rat e Source bv 
entering the Customer Num ber if known or bv selectin g to do an advanced search for a Customer.) 

2.1.9 if the rate source selected is not found, the use case continues at alternate flo w (Rate Source Not 
on Fiie^ . Otherwise, the use case continues along the basic flow. 

2. 1 . 1 0 The user initiates the rate search. 

2.1.11 The system uses the ECARS 10 Wrapper to search SI for the appropriate rates based on the 
criteria entered. The system receives the appropriate processing information from the ECARS 1.0 
Wrapper. 

2.1.12 The system displays the customer number for the ra te source, the rental type and the rate type for 
the rate source entered. If the rate source has multiple rate types that are retrieved, the use case 
continues at alternate flow (Multiple Rate Types). If the rate source has no rate type, the use case 
continues at alternative flow (No Rate Type). 

2.113 The system uses the rate type retrieved for the customer number entered. 

2.1,14 The system displays the rate table for that customer based on the group and branch, the rate 
source chosen, the pick up date, and rate type. 
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2.1.15 The svstem displays the results of the rate search, accordina fc 

\ the Default Sort Order, in rate 


table form to the user. If the search returned no rates, the use case continues at alternate flow (No 
Rates). 

2.116 The svstem displays the rates for the following headers: 

Rate Mileage Excess charge 

The following rates are displayed under the column headers: 

Hourly rate: ( Hourly rates are not filled by the svstem u nless turned on when input into CM121 
Daily rate 
Weekly rate 
Monthly rate 

Additional rate information displayed to the user: 

Account Deta ils: S pecial Instructions (as set up within AACM12 on the current ECARS 1.0 system) 

• 2 "Hot Lines" 

• Discounts 

• Rules 

• Products 

2.1.17 The user can perform the following options: 

• The user can select anot her Rate Source and the use case continues at ( )o f the basic 
flow. 

• The user can select a car class and associated rates from the table to attach to the 
reservation. The use case continues at f ) of the basic flow. 

• The user can cancel q uote a rate and the use case ends. 

• The user can enter a vehicle preference and the use case continues at alternate (Vehicle 
Preferences) 

• The user can select a billing cycle type. If the user decides to do this, the use case continues 
at alternate (Billing Cycle) 

2.1.18 The user selects one car class from the table. 

2.119 The svstem populates all rates associated with the car class selected on the reservation. 
2.1.20 The user has the option to do one of the following: 

• Ihejjsercan select another Rate Source and the u se case continues at ( ) of the basic 
flow. 

• The user can select another Rate Type and the use case continues at ( ) of th e basic flow. 

• The user can view account details . The use case continues at alternative flow (Account 
Details) 

• The user can chance a rate . The use case continues at alternative flow (Change a Rate) 

• Enter or View Package Specials . The use case initiates the Dates use Case. 

• The user ca n com plete the reservation . The use case initiates the Create Reservation use 
case. 
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• The user can cancel emote a rate. 

• The user can enter a vehicle preference and the use case continues at alternate (Vehicle 
Preferences) 

• The user can select a billing cycle type. If the user decides to do this, the use case continues 
at alternate (Billing Cycle) 

2.1.21 The use case ends. 


2.2 UK. Ireland. Germany Subflow 

2.2.1 The system displays all dates/rates criteria fields, allowing the user to enter specific search criteria 
from Table A. Differences can be seen in Tables C. D. E: 

Table A 

BASELINE SET OF REQUIREMENTS; 

Dates/Rate s criteria required to quote a set of rates: 

• Pick-Up Branch (defaults to termina l^ group 

• Pick Up Date (defaults to current d Mof^o„pjck 
up date is entered. 

• Rate Source (drop down of valid doma in 
values) or 

• Customer Number (text entry box). 

• Rate Tvpe (i.e. internal, warranty, cs pay, etc... 
from SI) 

Additional opti onal criter ia to quote rate: 

• Return Date (defaults to one calendar dav after 
RcLup^at^iLQ^ate is entered) (Note: 
Return date is req uire d for UM and Tiered 
rates) 

(Note: Tfa ejagLmaYJy pe within t h^CuglomerJjame, 
£MSD3aJ^SL(£M^ffilg Numb er). Rate Type. Branch 
Rates, and (Branch Rates )^RMeJTypej) r select from the 
list. 


Table C 

UK Differe nces to Base line Requirements: 

* Entering Rate So-Ulg^dojiJoi^^^ev^J^fels 

• Rate Tvpe (Will be added with new VRS) 
(Note: UK SI does n ot currently support the ECARS 
1 .0 Wrapper for retrieving rates.) 


Table P; 

Ireland Differences to Baseline Requirements: 

* Eutering R ate Source does n ot retrieve rates. 

♦ Rate Type (Will be added with new VRS) 
(Note: Irish SI does not currently sup port the ECARS 
1 .0 Wrapper for retrieving rates.) 
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Table E; 

Germany Di fferences tn Baseline Requirements: 

0 Entering Rate Source does not retrieve rates. 

• Rate Tvoe ( Will be added with new VRS) 
(Note: German SI does not currently support the 
ECARS 1.0 Wrapper &rreU^m^ratesJ 


2.2.2 The user e nters a pi ck-up date (this may h ave alread y been entered) and may enter a rate source. 

2.2.3 If no pick up date is entered T the system uses a default date of the cu rrent date. 

(Note: The user uses the Si programs in ECARS 1 .0, as they currently do, to look up the rates for the 
rate source.) 

2.2.4 The user manuailv enters a rate into the ECARS 2.0 re servation from SI... 

2.2.5 The user can perform the following op tions: 

• The user can overwrite th e Rate Source and the use case continues at i ) of th e basic flow. 

• The user ca n overwrite the rate entered. The use case continues at alternative flow (Change 
a Rate) 

• View the VLF Ranges. The use case continues at alternate (VLF Ranges). 

• The user ca n complete the reservation. The use case initiates the Create Reservation use 
case. 

• The user can cancel quote a rate . 

2.2.6 The use case ends. 


2.3 Alternative Flows 

2.3.1 Account Not Found 

2.3.1.1 The system displays a message to the user letting them know that No Account Matches or 
records were found. 

2.3.1.2 The use case continues at ( ). 

2.3.2 Branch Short List 

2.3.2.1 The system retrieves and displays the Branch Short list . The columns that are displayed to the 
user are (from left to right). 

• Account name 

• Leaacv Customer Number 

• Account type 

• Owning Grou p and Branch 

• Address 

• State 

• Zifi 

• Phone Number^ 
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2.3.2.2 The user selects an account from the list 

2.3.2.3 The system retrieves and displays the following information 

• Account name 

• Legacy Cu stomer Number 

• Account tvoe 

• Owning Group and Branch 

• Address 

• QM 

• State 

• Phone Number(s) 
2.3.3 Account Name 

2.3.3.1 From the basic flow, the system displays an area with all the fields emptied out so that the user 
can enter s earch criteria . The fields tha t are available are: 

• Group. This includes an U A H Groups" option. 

• Account Name 

• Account Phone Number^ 

• Account Tvoe. This includes an "A il" option. (See Special Requirements for the list 
of valid Account Types) 

2.3.3.2 The user enters an Account Name and selects "All" as the Account Type. * 

2.3.3.3 The user initiates the search 

2.3.3.4 The system validates the search criteria. If only an account type is entere d, the system will 
prompt the user that a t least on e other crite rion must be selected . If only a group is chosen, the system 
will prompt the user that at least one other criterion must be_selected. 

2.3.3.5 The system checks the status of the search. If No Account Matches are found, the use case 
continues at alternate (No Account Matches). 

2.3.3.6 The s ystem displays the matches to the us er in a su mmary list . The colum ns that are displayed 
to the use r are: /fro m left to right) 

• Account name 

• Leaacv Customer Number 

• Account type 

• Owning Group and Branch 

• Address 

• QM 

• Slate 

• Phone Numbers 

2.3.3.7 The user can do any of the following options: 

• Select an account from the summary list . If the user chooses this option, the use case 
continues at ( ) in the basic flow 

• Clear the se arch criteria . If the user chooses this option, the use case continues at ( ) of the 
Account Name alternative flow. 

• Search again . If the user chooses this option, the use case continues at ( ) of the Account 
Name alternative flow. 

• Exit. If the user chooses this option, the use case continues at ( ) in the basic flow. 
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2.3.4 View Rate fo r Single Car Class 

2.3.4.1 From ( ) of the basic flow, the user chooses to view the rates associated with th e rate agreement 
retrieved bv the system for the car class selected. 

2.3.4.2 The system displays the results of the r ate search for the car class entered, acc ording to the 
Default Sort Order, in tab le form to the user. 

2.3.4.3 The system displays the rates for the following headers: 

Rate Milea ge Excess charge 

The following rates are displayed under the column h eaders: 

Hourly rate: (Hourly rate s are not filled by the syst em unless turned on when input into CM^2) 

Dai'V rate 
Weekly rate 
Monthly rate 

Additional r ate information displayed to the user: 

Account Details: Special Instructions fas set up within AACM12 on the current ECAR S 1.0 system) , 

• 2 "Hot Lines" 

• Discounts 

• Rules t 

• Products 

2.3.4.4 The use case ends. 

2.3.5 Account Details 

2.3.5.1 The user chooses to see more details about the selected Customer Account. 

2.3.5.2 The system displays an ar ea that shows the following details about the Customer Account: 

Account Details fas set up within AACM12 on the current ECARS 10 system^ 

• Account Mame 

• Account Number 

• Account Type 

• Address 

• QM 

• State 

, • Zip Code 

• Phone Number (all phone numbers associated) 

2.3.5.3 The user is done looking at the information and the use case continues at ( ) within the basic 
flow. 

2.3.6 Change a Rate 

2.3.6.1 After a rate is selected by the user an d po pulated into the rate quoted field bv the system, the 
user has the ability to overwrite the rate in the reservation and the use case continues at ( ) in the basic 
flow. 

2.3.7 Multiple Rate Types 

2.3.7.1 The system w ill display a li st of rate types for an Accou nt fas defined in Sh if there are multiple 
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2.3.7.2 The user selects one rate type from the list and the use case continues at ( ) in the basic flow. 

2.3.8 No Rate Type 

2.3.8.1 If there is no Rate Type, t he system uses the Standard Rate Source for the selected Rate 
Source and the use case continues at ( ) in the basic flow. If there are no standard rates for the Rate 
Source then the use case continues at alternative flow (No Standard rates). 

2.3.9 No Rates 

2.3.9.1 If the account chosen does not have rates f either through an active or inactive agreement), then 
the system should not return rates. The system will dis play a message "No rates were found". The use 
case continues at ( ) of the basic flow. 

2.3.10 Setect a Car Class 

2.3.10.1 The system makes available, valid classes determin ed b y location and the combination of rate 
source / rate type. 

2.3.10.2 To select a vehicle class, the user chooses a vehicle class from the list displayed or the user 
may enter data in a text entry box. As characters are entered that match available vehicle classes, the 
list is positioned to the class that matches the characters entered. (Note: Only one Class can be 


2.3.10.3 The syste m populates rates with values that match the car class/r ate source/r ate type chosen. 
Mileage is defaulted appropriately, and the a ppropriate billing cvcle is defaulted. 

( Note : Mileage columns either display the word "UNLIMITED" and the Mileage Extra Charge column is 
populated with appropriately formatted zeros or the Mile age column mav have whole nu mbers which 
represent the number of miles free for that per and the Mileage Extra Charge column has an orooerlv 
formatted amount.) 

2.3.10.4 The user has the ability to add free tex t on the car class. 
2.3.11 VLF Ranges 

2.3.11.1 If the Group/Branch is within a VLF Group, the system provides an area for the user to view the - 
VLF Fee Ranges . (NOTE: this function should be available at any point within the Use case) 

2.3.11.2 The user chooses to view the VLF Ranges 

2.3.11.3 The system retrieves and displays a summary table with the follo wing columns to the user : 

• Group Number 

• Ranoe For fa list of car cla sses within the group an dJ^mupD 

• Daily VLF fee (Broken down bv Low. Hioh. Averaged 

See Example below for table layout 

2.3.11.4 The user is done viewing the table, and the use ca se continues at back in the Basic flow. 

3- Special Requirements. Quote Rates 

(NOTE: 3.1 throu gh 3X2 are rules for phase 2. For pilot, the user will enter rental type or select from a list 
of valid rental tvoes^ 

3.1 Based on the following rules the rental ty pe is defaulted on the window: 
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3.1.1 If a Account Rate Source is selected: 

Customer Type Rental Type Rilling Cvrie 

Employee Other 24 hour 

Insurance Insurance Calendar Day 

Bodvshop Bodvshop Calendar Day 

Dealership Dealership 24 hour 

Corporate Corporate 24 hour 

Government Corporate 24 hour 

Fleet Corporate 24 hour 

Qther ° the r 24hour 


^ 3.1.2 If a branch default is defaulted based on customer type or is selected bv the user t he following 
T*l rules applv: 

Q Branch Default Rental Tvnc 


iJ Allstate Insurance 


:i! Bodvshop 

5 S 

Bodvshop 

Z1 Corporate 

Corporate 

Li i Dealership 

Dealership 

* Emolovee 

Other 

:,, , Entertainment 

Corporate 

jlj Fleet 

Corporate 

ill Government 

Corporate 

?** Insurance 

Insurance 

Lease Customer 

Corporate 


Other Other 


Utilization Management Blank 

EsSiL Retail 

3.2 The Logic for SI comments retrieval is the same the ECARS 1.0 Wrapper. 

3.3 If one billing type in SI (Rate Type in ECAR S 2.01 is returned for the customer then the rules 
listed in the special requirements section should be d isplayed for that customer. If more than 
one billing type is returned and the user has not selected the Rate Type vet, than the rules will not 
be displayed. Once the user has selected the Rate Tvoe the rules associated to that rate type 
would be displayed. 

3.4 The available classes are determined bv the locat ion and the combination of rate source / rate 
type. The rate information depends on the rate source, rate tvoe and vehicle class . Not every 
rate is always available. {This needs to be clarified in a meeting to take place during the week of 
6/25) 

3.5 Mileage columns either display the word "No Charge" and the Mileage Extra Charge column is 
populated with appro priately formatted zeros or the Mileage column mav have whole numbers 
which represent the number of miles free for tha t ner and the Mileage Extra Charge column has a 
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properly form atted amount 


Rate Source Drop down behavior: 

3.5.1 Multiple Bill-To's 

3.5.1.1 The user en ters multiple Bill-to's into the reservation . 

3.5.1.2 The system retrieves the first customer selected as th e first available Rate Source to be selected 
in the rate source list, (identified by a customer selection area such as Bill To 1) during the reservation 
transaction . The use case continues at ( ) of the basic flow. 

3.5.2 Utilization Management 

3.5.2.1 If there are no Bill To customers and the pickup branch is a utilization m anagement branch. 
"Utilization Man agement" is available as the first selection in the rate source drop down list but the user is 
able to selec t other sour ces for use. 

3.5.2.2 The user sel ects the Utilization Management option from the Rate Source list. 

3.5.2.3 The utilization manage ment system is checked for the pic ku p branch. The syste m uses the start 
and end date of the rental to determine the appropriate day's f 1 Dav. 2 Day. 3 Dav. or 4 Dav) rate to 
default as the daily rate . When th e system che cks for UM rates . the User must kev in a pick -up date and 
time as well as a return date and ti me before the system will populate a ny UM rates 

3.5.2.4 If the user selects the Utilization Management option an d both sets of dates and times are not 
populated the system will display a feedback error message and the use case continues at ( ), otherwise 
the use case continues at ( ) of the basic flow. 

3.5.3 Bill-To 

3.5.3.1 If there is a Bill To customer, that custom er is defaulted and used for the Rate Source. 

3.5.3.2 The user is able to select another rate source. This can be done by selecting another rate 
source from the drop down T entering a customer number or using the advanced search. (These functions 
are described in the basic and alternative flows) 

3.5.4 Referral 

3.5.4.1 If there are no Bill To customers and there is a Referral customer that referral customer is 
available as the first selection in the R ate Source drop down list 

3.5.4.2 The user is able to select other customers for use. De fault the Customer Number to first 
selected . (Rate Type box is enabled). 

3.5.4.3 If a Source ID (The rate source's name. For examp le State Farm lnsurance-St. Louis is defined 
prior to the User selecting rates and there is no Bill-To. the so urce ID should be on the too of the list 
within the Rate Source drop down box. When the User gets to the Vehicle rates screen, Rate Source will 
be blank. 

3.5.5 Shop 

3.5.5.1 If there are no Bill To customers, and there are Referral and Sho p customers, the Referral source 
is available as the first selection in the Rate Source drop down list but the user is able to select other 
customers for use. Default the Customer Number to first selected. (Rate Type box is enabled). 
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3-5.6 Not on File Bill-To Ws\ 

3.5.6.1 If the Bill-to is a Not on Fil e Bill-to f9's type customer). Both Rate Source and Customer Number 
will be blank and the User will have the option to fill in these areas by using the drop down or search 
buttons . The use case continues at ( ) of the basic flow 

4. Pre-Conditions 

4.1 The user successfully logs onto the application. 

5. Post-Conditions 

6. System Generated Notes ~ Rates 

A note should be generated when anv of the follow ing events occur : 


Event 


Note Text 


When To Generate 


The Rate Source and/or Account Number are changed 


Rate Source "XXXXX" was changed to 
"XXXXX" 


Edit 


The Rate Typ e is chans 


Rate Type "XXXX" was changed to 
"XXXX" 


Edit 


The Car Class is changed 


as 


Car Class "XXXX" was changed to 
"XXXX" 


Edit 


AftetS rat e source and car class has been chosen, the user manually 


chanfl&myofl 

"la 
I - 5 

r 7. 

hi 8- 


licle rate table . 


What rate values were changed and 
what the old and new values are. 


Create/Edit 


Extension Points 

Functionality to be included in Future Scope - Quote Rates. 

1. Connectivity to the new VRS (Perots for UK. Ireland. Germany. 

2. The option to view account details in UK. Ireland, and Germany comes with connectivity to 
the new VRS. 

3. Multiple rate types for UK. Ireland. Germany comes with the new VRS, 

4. Enterjpaa^ar class in res ervation for UK. Ireland and Germany. 

5. Branch Short List for UK. Ireland and Germany will be determined during a meeting to be 
held du ring the we ek of 6/25,. 

6. Rate Type for UK. Ireland and Germany. 

7. Rate sourc e drop down behavior for multiple BiSI-To's comes with connectivity to the new 
VRS for all countries. 


9. Current VLF Groups 

• California 
L 32 

ii. 30 

iii. 54 

iv. 23 

• Hawaii 
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i. 36 

This data is stored in Veh_Lisc_Fee_St table on Oracle and VT010P file on Legacy. 

10. Sample VLF Range Table 



Daily VLF Ranges 

Range For 

Low 

High 

Average 

GROUP 

.26 

2.33 

.78 

ECAR 

.42 

.59 

.52 

CCAR 

.39 

.73 

.59 

ICAR 

.26 

.83 

.59 

SCAR 

.34 

.96 

.74 

FCAR 

.40 

1.01 

.81 

PCAR 

.64 

1.19 

.92 

LCAR 

.50 

1.62 

.97 

LCAR1 

.86 

1.85 

1.59 

LTAR 

.54 

1.13 

.88 

MVAR 

.73 

1.16 

1.03 

XCAR1 

.77 

1.95 

1.43 

XXAR 

.98 

1.92 

1.61 

XVARP 

.81 

1.35 

1.13 

XFAR 

.78 

1.42 

1.16 

XFAR1 

1.07 

2.09 

1.38 

XPAR 

.60 

1.11 

.89 


11. J&MQ's 
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Finally added special requirements 3 thru 6. 

ML Pallia 
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1.5 
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9/7/01 

1.6 
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L. Moellman 
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Use Case Specification: Referral 

1. Referral 

1.1 Brief Description 

This use case describes the interactions a user will take when a renter is referred to Enterprise by a 
promotional discount, an Account, a TV ad campaign or any other method of attracting Renters, or an 
employee of Enterprise refers a renter (Employees can refer themself as well). 

2. Flow of Events 
2-1 Basic Flow 

2.1 .1 This use case can be initiated at any point during the Reservation/Open Ticket process. 

2.1.2 Depending o n the person makin g the Reservation/O pen Ticket, the user will use one of the two 
sub-flows . More commonly, the Account Referral Sub-flow is used. 

2-2 Account Referral Sub-Flow 

2.2.1 The s ystem d ispla ys an area for the user to select a n Account from the Branch Short List. The 
system also giv es the user th e option to : 

• Enter an Account Number . If the user chooses this option, the use case continues alternate 
(Account Number). 

• Search for an Account . If the user selects this option, the use case continues at alternate 
(Search) 

2.2.2 The system retrieves and d is plays the Bra nch Short list. The columns that are displayed to the 
user are (from left to right). If the physical terminal location is in Europe, the use case continues 
at Alternate (European Branch Short List). 

• Account name 

• Account Number 
a Account tvoe 

• Owning Group and Branch 

• Address 

• g& 

• State 

• Phone Numberfsl 

2.2.3 The user selects an ac count from the list . If the user does not choose an account from the list, 
the use case continues at (2.2.1) in the Account Referral Sub-Flow. 

2.2.4 The system retrieves and displays the following information 

• Account name 

• Account Number 

• Account tvoe 

• Owning Grou p and Branch 

• Address 

• gt¥ 

• StaM 


Phone Number^ 
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2.2.5 The user has the optio n to select an Accou nt contact for the select ed account, select a different 
account or view the Ac count detai ls of the selected account. If the user chooses to view "The 
Account Details", the use case continues at alternate (Account Details). If the user chooses to 
select a different account, the use case continues at alternate (2.2.1) within the Account Referral 
Sub-Flow. 

2.2.6 The user cho oses to view the list of contacts for th e selected account. 

2.2.7 The system displays the Account C ontact list to the user, if there are no Contacts identified for a 
particular Account, the use case continues at alternate (No Contacts). The column displayed to 
iheuser will be t he following : 

• Name (First Name Last Name) 

• Telephone Number 

• Extension 

2.2.8 The user hgjj hj option to select a contact from the list or add a New Contact If the user 
chooses to add a new contact, the use case continues at alternate (Add New Contact). 

2.2.9 The user selects a conta ct from the list 

2.2.10 The system displays the name of the contact and the contact's phone number to the user . The 
system also allows the user the ability to change the contact phone number . (NOTE: if the user 
changes the phone number, it will only save with the transaction. It will not be stored to the 
reference data) * 

2.2.11 From here, the user can navigate to anv other area within the Reservation/Open Ticket and the 
system initiates the Reservation Navigation Use Case 

2.2.12 The use case ends 

2.3 Employee Re ferral Sub-Flow 

2.3.1 The syste m disp la ys an area for the user to perform the following options : 

• A field to enter an Employee Number 

• Search for an Employee . If the user chooses to search for an Employee, the use case 
continues at alternate (Employee Search) 

2.3.2 The user types in an em ployee numbej . 

2.3.3 The user initiates the search. 

2.3.4 The system checks the status of the search. If No Employee Matches are found, the use case 
continues at alternate (No Employee Matches) If the search results in only one match, the use 
case continues in this Sub-Flow. 

2.3.5 The system displays the following information to the user 

• Employee Name 

• Group and Branch Number - Group and Branch Description 

• Department 

• Title 

2.3.6 From here, the user can navigate to anv other area within the Reservation/Open Ticket and the 
system initiates the Reservation Navigation Use Case 

2.3.7 The use case ends 
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2.4 Alternative Flows 
2.4.1 Search 

2.4. 1 . 1 From the Account Referral Sub-flo w, the system disp lays an area with all the fields e mptied out 
so that the user can enter search criteria. The fields that are available are: 

• Group . For reservation pilot, this will be defaulted to the physical terminal location 
and the user will not be able to cha nge the group . This includes an "Ail Groups" 
option. 

• Account Name 

• Account Pho ne Numbers) 

• Account Type . This includes an "All" option. (See Special Requirements for the list 
of valid Account Types) 

2.4.1.2 The user enters an Account Name and selects "Ail" as the Account Type . 

2.4. 1 .3 The user initiates the search 

2.4.1.4 The system validates the search criteria . If only an account type is entered, the system will 
prompt the user that at least one other criterion must be selected . If only a group is chosen, the 
system will prompt the user that at least one other criterion must be selected . 

2.4.1 .5 The system checks the status of the search . If No Account Matches are found, the use case 
continues at alternate (No Account Matches). ^ 

2.4.1.6 The system displays the matches to the user in a summary list . Th^ojymos that are displayed 
=>r are: (from le ft to rights 

Acco unt name 
Account Number 
Account type 

Owning Group and B ranch 



Phone Number(s) 

2.4.1.7 The user can do any of t he foltawingjptioos : 

• Select an account from the summary list . If the user chooses this option, the use case 
continues at (2.2.6) in the Account Referral Sub-flow 

• Clear the search criteria . if the user chooses this option, the use case continues at (2.5.2.1 ) 
of the Search Alternate. 

• Search again . If the user chooses this option, the use case continues at (2.5.2.2) of the 
Search Alternate. 

• Exit . If the user chooses this option, the use case continues at (2.2.2) in the Account 
Referral Sub-flow. 

2.4.2 Enter an A ccount Number 

2.4.2. 1 From the Account Referral Sub-Flow, the user chooses to enter an Account Number. 

2.4.2.2 The user ty pes in an Acc ount Numb er and initiate s a search for all the information associated 
with the entered Account Number . 

2.4.3 The system checks the status of the search, if No Account Matches are found, the use case 
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continues at alternate (No Account matches). If More than one Account match is found, the use 
case continues at alternate (More than One Account Match). If the search results in only one 
match, the use case continues at (2.2.5) within the Account Referral Sub-Flow. 

2.4.4 No Account Matches 

2.4.4.1 From the Account Referral Sub-Flow, the system displays a message to the user l etting them 
know that No Account Matches or records were found . 

2.4.4.2 The use case continues at (2.2.2) within the Account Referral Sub-Flow. 

2.4.5 More Than One Account Match 

2.4.5.1 The system displays a summary list of the matches to the user . The columns that will be 
displayed in the summary list are (from left to right): 

• Account name 

• Account Number 

• Account typg 

• Address 



• Phone Num ber(s) 

2.4.5.2 The user has the option to select an a ccount from the list or to exit . if the user selects an 

Account from the list, the use case continues at (2.2.6) within the Account Referral Sub-Flow. If 
the user chooses to exit the list without selecting an Account, the use case continues at (2.2.2) 
within the Account Referral Sub-Flow. 

2.4.6 Account Details 

2.4.6.1 From the Account Referral Sub-Flow, the user chooses to see the details about the selected 
Account. 

2.4.6.2 The system displays an ar ea that shows the following details about the Account : 

Account Details 

• Account Name 

• Account Number 

• Account Typ e 

• Address 

• State 

• Zip Code 

• Phone Number(s) 
Special In structions 

• 2 "Hot" lines 

• Miscellaneous Information 

• Discounts 

• Rules 

• Products 
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2.4.6.3 The user is done looking at the information and the use case continues at (2.2.6) with in the 
Account Referral Sub-flow. 

2.4.7 No Contacts 

2.4.7.1 From the Account Referral Sub-Flow, the system d isplays a m essage, letting the user know that 
no contact ha ve been set up for thi s Account 

2.4.7.2 The user can either add a new conta ct or exit . If the user chooses to add a new contact, the use 
case continues at alternate (Add New Contact). If the user chooses to exit, the use case 
continues at (2.2.7) within the Account Referral Sub-flow. 

2.4.8 Add New Contact 

2.4.8. 1 From the Account Referral Sub-Flow, the system displays an area for the user to enter Contact 
information . The fields th at can be entered are either : 

• Last Name 
AND/OR 

• First Name 

2.4.8.2 The user en ters a first o r last name and accepts the new contact informatjoomter^ . If the user 
chooses to exit, the use case continues at (2.2.7) with in the Account Referral Sub-Flow. 

2.4.8.3 The system associates the new contact ad ded to the Ac ofMltshflgfiQ and the use case 
continues at (2,2. 12) with in the Account Referral Sub-Flow. * 

2.4.9 Employee Sea rch 

2.4.9. 1 From the Employee Referral sub-flow, the user chooses to search for an employee . 

2.4.9.2 The system d isplays an area with all the search criteria fields emptied out . The search criteria 
fields available for the user to enter are : 

• Employee Last name 

• Employee Fi rst name 

2.4.9.3 The user enters a Last N ame and a F irst name . If the user enters just a First Name and No Last 
Name, the use case continues at alternate (First Name Only). 

2.4.9.4 


2.4.9.5 The system checks the status of the search. If No Employee Matches are found, the use case 
continues at alternate (No Employee Matches). 

2.4.9.6 The system displays the matches to the user in a summary list . The columns that are displayed 
to the user are : (from left to right) 

• Employee Name 

• Employee Number 

• Group and Branch Number - Group and Branch Description 

• Title 

2.4.9.7 The user can do any of the following options : 

• Select an e mployee fro m the summary list . If the user chooses this option, the use case 
continues at (2.3.5) in the Employee Referral Sub-flow 
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• Clear the search catena , If the user chooses this option, the use case continues at (2.4.8.3) 
of the alternate (Employee Search). 

• Search again . If the user chooses this option, the use case continues at (2.4.8.3) of the 
alternate (Employee Search) 

• gxjt . If the user chooses this option, the use case continues at (2.3.1) in the Employee 
Referral Sub-flow. 

2.4.10 First Name Only 

2.4.10.1 From the alternate (Employee Search), the system will display a message to the user that they 
mystentaer.aLiast name along with a first name . 

2.4.10.2 The use case continues at (2.4.8,3) in the alternate (Employee Search). 

2.4.11 No Employee Matches 

2.4.1 1.1 From the Employee Referral Sub-Flow or the alternate (Employee Search), the system displays 
that no employees match the criteria entered . 

2.4.1 1 .2 The use case continues at (2.1.3) within the Employee Referral sub-flow or (2.4.8.2) in the 
alternate (Employee Search). 

2.4.12 European Branch Short Ust 

2.4. 1 2. 1 From the account referral sub-flow, the system retrieves and displays the Euro pean Branch 
short list. (NOTE: This list i s comprise d of all accou nts that have an owning Group that equals 
the Group of the Phy sical termina l's location.) The columns displayed to the user are: 

• Account Name 

• Account Number 

• Account Type 

• Owning Group/ Branch 

• Address 

• CM 

• State 

• Phone Num berfs) 

2.4.12.2 The user selects an account from the list that is displayed , 

2.4.12.3 The use case continues at (2.2.4) within the account referral sub-flow. 
3. Special Requirements - Referral UC 

1. A contact must be selected for every Account that jj selected as a Referral. NOTE: This 
is an Open Ticket requirement only. Reservations do not require a contact. 

2. The valid Account Types that are displayed to the user in Search are : 


o 
o 

Corporate 

o 

Government 

o 

Fleet 

o 

Dealership 

o 

insurance 

o 

Other 
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4. 

5. 

5.1 
6. 
7. 

7.1 


3. For North America, the Branch Short List is curr ently ..being g enerated from the existing 
Legacy system and is being stored in a table on the Oracle database . 

4. The system should not search or display fo r any deactivated or d eleted accounts . 

5. The user m ust have the ability to cance l a search at anv time during the search . 

6. An account and contact or an emplo yee number must be selected before the user can 
complete an open ticket . 

7. If a Fleet type Account is selected, the system should not allow the user to add a new 
contact 

8. The system must allow the user to select one Account Type or "All" during the Search , 

9. When a user adds a new contact, that contact must be saved to the database and be 
available for selection for any future transactions . 

Future Scope 

The ability to view Account Details. Account Details includes the 2 "Hot Lines", Products, 
Miscellaneous Information, Discounts and Rules as set up in SI. 

Pre-Conditions 

The user successfully initiated the Create Reservation Use Case 
Post-Conditions # 
System Generated Notes -Referral 

Notes should be generated when any of the following events occur 


Evejf 


Note Text 


When to generate 


Th^er changes the Referral Account_ 
The ;! tiser changes the referral contact, 
f Thf Wer ral account is the same^ 


Referral Account "XXXXX" was changed to "XXXXXX* 


Edit 


Referral Contact "XXXX" was changed to "XXXX" for Referral 
Account "XXXX" 


Edit 


lot on file" contact 


Not on File Contact "First Name, Last Name" was added for Referral 
Account "XXXXX". 


Create/Edit 


8. Extension Points 

9, Questions 
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Use Case Specification: Bill-to 

1. Bill-to 

1.1 Brief Description 

This use case describes the "Bill-to process" within the context of the ticket or the reservation. The "Bill-to 
process" is limited here to adding and deleting an account number as a Bill-to, and adding, changing, 
extending and deleting an authorization. 

This use case will encompass all of the requirements that are relevant from ECARS 1 .0 as well as those 
from VRS which are deemed part of the 1 st phase of ECARS 2.0. This use case only pertains to non- 
ARMS transactions. 
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2. Flow of Events 

2.1 Basic Flow 

2.1.1 Add a Bill-to 

2.1.1.1 The user navigates, within the Ticket or the Reservation to the Bill-to area. 

2.1.1.2 The system allows the user to indica te who will be billed. 

2.1.1.3 The user can search for an account bv name or s/he can miter the account number directly. 

2114 If the user elects to search for the account the system will first provide a list of the accounts 
alread y in use on the ticket or reservation (if applicable) and provide a list of the branch's most 
nnmmonlv used accounts, as determined bv the criteria in the branch description in TXQ1. UJM 
user elects to use an account not i n this list, thev can search across ail of the accounts on file . 

2115 If there is no account in the system for the intended bill-to, see alternative flow: Account not on 

file. If the user elects to enter the account numher w ithout sea^h the system mi ist validate the 
account before proceeding . 

2 116 The user selects a contact . If the contact is not found, the user elects to add one and enters the 
contact 1 s full name phone m imher and phone number. Either the first name or last name is 
required. This is saved on the ticket / re servation, as well as heina added as a contact for the 
account. 

2.1.1.7 The user mu st select an authorization status. 

2.1.1.8 System loos the details in the "Notes". 

2.1.1.9 Use Case Ends 

2.2 Alternative Flows 

2.2.1 Remove a Bill-to 

2.2.1.1 The user navigates within the Ticket or th e Reservation to the Bill-to area. 

2.2.1.2 The user indicates that s/he wishes to remove a Bill-to. 

2213 The user selects the Riil-to account number w hir.h s/he wishes to remove from among the bill-tos 
on the ticket o r reservation. Anv hill-to on the ticket which has at least one ARMS authorization 
^Tniated to it cannnTheTemoved anri therefore shouldn't he presented to the user as an 


2.2.1.4 The system displays to the use r all of the details of anv authorizations associated will the Bill-to 
for that ticket or reservation alon g with the option to cancel their choice. 

2.2.1.5 User elects to continue. If they elect to na nce! the use case ends . 

2 217 If there are other Bill-tos on the ticket or rese ction and the y are a higher number bill-to. then 

thev will he chanced to a lower number, ^nr evamnle if Rill-to One iS Smith Insurance and Bill, 
♦n Twn is Rrnwn Auto Roriv and the user removes Smith insurance from the reservatlOn/tlCKet, 
then Brown Auto Rodv becomes Bill-to One.) 
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2.2. 1 .8 The use case ends. 

2.2.2 Add author ization details 

The user navigates, within the Ticket or the Reservation, to the Bill-to area . 

The user indicates that s/he wishes to add an authorization. 

The system presents the user 


itus (Auth orized, P* 


Hon, PedinejiJIi 


Reimbursed. Pending Call at Open) 

• Daily amount of authorization 

• Itemfe) authorized 

• Beginning date and time authorized 

• Ending date and time authorized 

• Final date of a uthorization fa.Ica. "Last Day") 

• Person from the bill-to nrgaTriratinn who gave the authorization. 

• Maximum amount of authorization 

• Maximum n umber of d?vs of authorization 

• Flat amount of authorization 

• "All charges" authorization 

• Information required bv the bill-to f mav be l imited bv legacy to the existing text 
fields for the CTlaim/PO/RO and Insured Name fieldsl 

in nrA*r m add an authorization. .thfcJlSfi U™-* change the authorization status to ^StolMjm 
^"red information as detennine d bv the situatior TTSee add dailv authorization, add authorization 
T» fl vimnm« flat authorization, last d^v and required infonmtjon forlhfclktaifc) 

ThP qvstem aiitomatipallv enters th» Hptoilc nf th«> authorization into the reservation 
thA Rnt^rpri^ employee who performed t h» w*«™»« m a. wall as all of the ass ociated details. 

The use case ends. 

2.2.2.1 Add dailv authorization 

The user indicates that s/he wishes to add a dailv authorization. 

User indicates the following: 

The amount per dav tha t is authorized. 

The item or items to which that a mount is to he applied. 

WWW or not thar amount inrlndp* tax or is MlH &^ whfeh a " OWS ttlP faXfffi> t0 ** ***** 
fho authorization. 

^ *»t» th. authorization fa ^fferHve. faffliBg rvde is 74 hour, then the time is also 

required . Thpse should default to the dat * time that the ticket was opened, or to the 
date and time of the reservation (if available^ 

ThP Pnd date of rbP authorization or rhe mimber nf Hays of the authorization. Tf the number 
of davs is ind icated, then thg system w ill determinp the end date. Tf a 24 hour b illin g cycle, 
rhen the time is also required. 
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The name of the person from the bill-to account who made the authorization. 

2.2.2.2 Add autho rization maximums 

The user indic ates that s/he wishes to ad d an authorization maximum. 

User indicates the following: 

The maximum amount that the bill-to can be billed, the maximum number of d ays that they 
can be billed, or both . If thev indicate both, the system will annlv whichever is the lesser^ 

The name of the person from the bill-to account who set the maximum. 

NOTE: The m aximum amount is a flat ma ximum - th ere will be no option to indicate an 
amount + tax, etc. . . 

2.2.2.3 Last Dav 

User indicates th e_fotedn^ 

The date bevond whic h no charges may be applied to the bill-to . If the ticket or reservation 
has a 24-hour billing cycle, then the time is requiredjoo. 

The name of the person from the bill-to account who set th e final date. 

2.2.3 Change Authorization Amount 

2.2.3.1 This allows the user to change an authorization which has already been entered. 

2.2.3.2 The user navigates, within the Ticket or the Reservation, to the Bill-to area. 

2.2.3.3 The user indicates that s/he wishes to chance the amount of an authorization for Bill-to. 


2.2.3.4 If the user wants to cha nge an existing amount for dates which have already been authorized. 
Of- s/he indicates the authorization that s/he wishes to change and changes it Because A RMS 

m authorizations cannot be changed by the user, the system should not make any ARMS 


0 authorizations available to them 

fvslt 


2.2.3.5 The system automatically enters the details of the authorization into the reservation or ticket 
notes detailing the Enterprise employee who performed the authorization as well as all of the 
associated details. 

2.2.3.6 The use case ends. 
2.2A Extend Authorization 

2.2.4.1 The user navigates, within the Ticket or the Reservation, to the Bill-to area. 

2.2.4.2 The user indicates that s/he wishes to extend an authorization for a specific Bill-to. The user 
should not have any authorizations available to them which are ARMS authorizations. 

2.2.4.3 The system presents the user with the end date of the most recent authorization amount and 
allows the m to change it 

2.2.4.4 if the user wishes to change the authorization amount, qo to the Change Authorization alternative 
flow. 

2.2.4.5 The user changes the end date to a date later than the date already in the authorization, lf&gy 
enter a date which is the same as the date already entered, then the use case ends, 

2.2.4.6 If the user attempts to change an end date for an a uthorization which has been "Last Paved". 
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then the system presents the us er with an informational message and asks them to confirm the 
change. If thev confirm, then the Last Da y Date is upd ated accordingly. The authorization status 
remains Terminated". 

2.2.4.7 The system automatically enters the details of the autho rization into the reservation or ticket 
notes detailing t he Enter prise employee who perfor med the authorization as well as all ofthg 
associated details. 

2.2.4.8 The use case ends. 

2.2.5 "Last Day" authorization 

2.2.5.1 The user navigates, within the Ticket or Reservation, to the Bill-to area. 

2.2.5.2 The system provides th e option to i ndicate that the end date of the authorization is final and 
cannot be changed. If the authorization is an ARMS authorization, this option is not available 
and the use case ends. 

2.2.5.3 The user elects to make t he end date o f the authorization the LAST DAY. 

2.2.5.4 The system automatically chances the authorization status to "Terminated" and enters the details 
of the authorization into the reservation or ticket notes detailing the Enterprise employee who 
performed the LAST DAY authorization as well as all of the associated details* 

2.2.5.5 The use case ends. 

2.2.6 Remove Au thorization 

2.2.6.1 The user navigates, within the Ticket or Reservation, to the Bill-to area. 

2.2.6.2 The user indicates that s/he wishes to remove a single authorization for a specific Bill-to. if the 
authorization is an ARMS authorization, this option is not available and the use case ends. 

2.2.6.3 The system presents an option to the user to cancel their choice , along w ith all of the details of 
the authorization they selected. The details include which itemfs^ the authorization applies to and 
the amount and dates covered. 

2.2.6.4 User elects to continue. Ifjtey^elesL to cancel the use case ends. 

2.2.6.5 If the authorization thev selected to remove is the only one on the ticket or reservation for that 
Bill-to. then the system reouires chances the authorization status to "Declined" but allows the 
user to change the authorization status to "Pending". 

2.2.6.6 The system automatic ally enters th e details of the authorization removal into the reservation or 
ticket notes detailing the Enterprise employee who performed the authorization as well as all of 
the associated details. 

2.2.6.7 The use case ends. 

2.2.7 Remove ait authorizations for a Biil-to Account 

2.2.7.1 The user navigates, within the Ticket or Reservation, to the Bill-to area. 

2.2.7.2 The user indicates that s/he wishes to remove all au thorizations for a^pecificBilko b t Y h ch ^^ ^ 

2.2.7.3 The system presents an option to the user to cancel their choice, aiona with all of the details of 
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the authorizations. The details include which itemfe} the authorizations apply to and the amounts 
and dates covered. 

2.2.7.4 User elects to continue, if thev elect to cancel, the use case ends. 

2.2.7.5 The system automatically enters th e details into the reservation or ticket notes de tailing the 
Enterprise em ployee who performed the authorization as well as all of the associated details. 

2.2.7.6 The use case ends. 

2.2.8 Account not on file 

2.2.8.1 The user navigates, within the Ticket or Reservation, to the Bill-to area. 

2.2.8.2 The user indicates that s7he wishes to bill an account which is not in the system. 

2.2.8.3 The system presents fields to enter the name of the account, the billing address information, 
phone number and name of a contact for that account. All of the information is required. Ihe 
address entry should follow the system standards which allow for the user to enter the zip code 
and address and have the system search for the appropriate city and state. If many city, state 
combinations are valid, the user should be allowed to select from them. 

2.2.8.4 The user completes all of the information. If they omit any part of the information and try to 
continue, the system provides a feedback message indicating which information is missing. Ih§ 
system allows the user to update thos e items. 

2.2.8.5 The system does not add this account to the account database. 

2.2.8.6 The system automatically enters the details of the addition of the "Not on file" account into the 
reservation or ticket notes detailing the Enterprise employee who performed the action as well as 
alt of the associated details. 

2.2.8.7 The use case ends. 

2.2.9 Adding Required Billing information 

2.2.9.1 The user navigates T within the Ticket or Reservation, to the Bill-to area. 

2.2.9.2 The user indicates that s/he wishes to add "Required Billing Information" 

2.2.9.3 The user indicates the account for which they want to add or update the information. 
information associated with bill-tos on the ticket which have at least one ARMS authorization 
associated to it cannot be changed and therefore, those accounts shouldn't be available to the 
user. 

2.2.9.4 The system makes the Claim/FQ/RQ and the insured Name fields available for edit. 

2.2.9.5 If the account has listed at least one of these fields as reguired and/or that specific formatting is 
necessary, then the system indicates which fteldls) is required and/or the format that the 
informatio n must be i n fif specified! 

2.2.9.6 The user enters as much information as is available. (The information isn't required until the 
ticket is closed.) 

2.2.9.7 The system automatically enters the details of the information, into the reservation or ticket notes 
detailing the Enterprise employee who performed the edit as well as all of the associated details. 

2.2.9.8 The use case ends. 
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3. Special Requirements - BiH-to 

3.1 Number of users 

Only one user should be allowed to update authorization information on a ticket or 
reservation at a time. 

Only one user shoul d be allo wed to ad d or rem ove bill-to account numbers on a ticket or 
reservation at a time. 

3.2 Callbacks 

Any update to authorizations should be taken into account bv the callbacks engine in 
generating callbacks to renters and Bill-tos. 

3.3 tielz 

If help text will be made available to the us ers, some e x planation of why ARMS-authorized 
bill-tos are treated differently wi ll be necessary. 

3.4 Authorization by car class 

When the user is adding an authorization amount, thev must be allowed to look up the 
amount usi ng a car class. Furtherm ore, if the retrieved rate is tiered, then the user must have 
the option ei ther to selec t one of the rates or to indicate that the authorization is tiered and 
thereby ass ociate all of the rates to the authorization. 

3.5 ARMS authorization 

Only one A RMS authorized accou nt can be on a ticket/ r eservation at a time. 

If a bill-to account receiv es an ARMS authorization and it is not in the bill-to ONE position, it 
must be c hanged to bill-to one a nd the other bill-tos must follow it . Therefore, if bill-to one 
is Joe's Body Shop (non-AMRS) and bill-to two is Allstate (ARMS) and Allstate sends an 
initial ARMS authorization, it becomes bill-to one and Joe's Body Shop becomes bill-to two. 

4. Pre-Conditions 
4.1 User logged In 

The user must be logged in to the reservation or ticket system. 

5. Post-Conditions 
5.1 None 

6. Extension Points 

6.1 None 

7. Questions 

7.1 Rate source 

How is adding a bill-to (or removing one) expected to impact the reservation or ticket's rate source? If no 
impact, should a message be provided to the user? 

7.2 European requirements 

European requirements still need to be documented. When will these be available? 
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7.3 ARMS 

Can the user change any Bill-to information on an ARMS ticket? 


7.4 System generated notes 

What details should be included in each note? 

7.5 Name of authorizer 

Should this name be free-form text or should a list of contacts for the account be used? If a list is optimal, 
then do omit the contact for "Not on File" bill-tos? 
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First Draft 

D. Beebe 

07/12/2001 

11 

Revisions based upon feedback from 
meeting with Mike P. and Jackie L. 

D. Beebe 

7/16/2001 
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1.2 

Revisions based upon feedback from 
Mary S. and Jon J. 

• "Accident" changed to "Damage." 

• Removed steps for user choosing 
to search for make and model. 

o Once a user selects a Year 
the list of possible models 
are displayed. 

o Once a user selects a 
Make the list of possible 
models is displayed. 

• Removed requirement that the user 
must select full (year, make, model) 
renter vehicle information. 

• Removed enabling the "Other 
Make", "Other Model" and "Other 

Pninr" fiolHc hacoH nnnn ciplpctino 

"Other" in the "Make", "Model" and 
"Color" fields. 

D. Beebe 

7/17/2001 

1.3 

Combined the Renter's Vehicle and 
Shop use oases oacK togeiner. 

(In the GUI ECARS and the Functional 
Specs these two areas were combined. 
However when Ciber worked on the 
baseline code they were separated. 
Based upon feedback from Mary and 
Jon for ECARS 2.0 Renter's Vehicle 
and Shop were merged.) 

D. Beebe 

7/24/2001 

1.4 

Updated "Add New Contact" to say that 
a user may enter the last and/or first 
name. The requirement previously 
stated that both were needed. 

D. Beebe 

7/30/2001 

1.5 

Added to Supplemental Requirements. 
Included all of the situations that the 
system should generate a note. 

D. Beebe 
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8/2/2001 


1.6 


1 ) Added domains for "Type of Loss" 

2) Added to Supplemental Specs that 
the system should generate a note 
when the user changes the renter's 
vehicle. 


D. Beebe 


8/3/2001 


1.7 


8/8/2001 


18 


8/9/2001 


1.9 


1) Added alternate "European Branch 
Short List" when selecting a Shop. 

2) Added German Vehicle and Class 
information alternate flow. 


D. Beebe 


Revision based upon feedback from 
Jon Jouris. Vehicle Notes will only be 
viewable from this screen and will not 
be saved to Notes. 


D. Beebe 


Revisions based upon feedback from 
Chris Carr 

1 . Default values of drop downs is 
"Blank" 

2. Removed step to search for full 
account information after selection 
as shop: system already did this in 
previous step, 

3. Removed viewing full account 
details. 

4. When selecting a "Not on File" 
account , added functionality to get 
city and state from zip/postal code. 


D. Beebe 


8/16/2001 


2.0 


1 . Changed telephone to phone. 

2. Corrected one change missed in 
version 1.4. 

3. The user can only select one type 
of loss. 

4. Removed exit option from No 
Contact alternate flow. 


D. Beebe 


8/20/2001 


8/28/2001 


2.1 
U 


Changed name of use case from 
Renter's Vehicle/Shop to Vehicle/Shop. 


D. Beebe 


1 . Added "Zero Days" to list of Theft 
Waiver Days 

2. Added note that "Theft Waiver 
Days" field is not displayed in 
Europe. 

3. Added note that the vehicle "Year" 
is not displayed in UK. 


D. Beebe 
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9/4/01 

2.3 

1 . Added two European requirements 
for system generated notes. 

2. Vehicle Year field is not present in 
UK or Ireland. 

3. License plate field is removed. 

4. Registration number field added for 
Europe. 

5. Zero theft waiver days removed. 

6. Date of Loss not required. 

D. Beebe 

9/6/01 

2.4 

1 . Added the values that are in the 
drop down for the class neia in 
Germany. 

D. Beebe 

9/7/01 

2.5 

Changed wording from Account Search 
to Search. 

Changed wording from Telephone 
Number to Phone Number. 

L Moellman 

9/19/2001 

2.6 

Separated the three system generated 
notes for when the user changes the 
renter's vehicle Year, Make and/or 
Model. 

D. Beebe 

0 

9/25/01 

2.7 

Added spec noting what information 
should display in the Navigation Bar for 
Vehicle/Shop 

D. Beebe 

10/23/2001 

2.8 

1 ) Removed system note "Not on File 
Account XXXX has been added as 
a Shop". 

2) Changed system note "Not on file 
contact XXXX was added for Shop 
Account XXXX" to "Not on file 
contact XXXX was added for 
Account XXXX" 

D. Beebe 

10/29/2001 

2.9 

1 ) Corrected "driveabie" to "drivabie*. 

2) Added requirements indicating 
what happens to fields when a 
reservation is edited. 

D. Beebe 

11/13/2001 

3.0 

1 ) Changed theft waiver days from 
"One Day", "Two Days", "Three 
Days" to "1 Day", "2 Days" and "3 
Days". 

2) Added system generated notes for 
Other Make and Other Model 

D. Beebe 
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11/20/2001 

3.1 

Removed requirement to have 

D. Beebe 



previously selected Bill-To and/or 




Referral appear at the top of the Branch 




Short List. 
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Use Case Specification: Vehicle/Shop 


1. Vehicle/Shop Use Case 

1.1 Brief Description 

This use case describes the how the user interacts with a system to indicate the renter's type of 
vehicle that is being repaired, notes about the vehicle, whether the vehicle is drivable, the type of 
loss, the date of loss and the theft waiver days. This use case also describes how the user 
interacts with a system to indicate which shop a renter's vehicle is being repaired at. 

2. Flow of Events 
2.1 Basic Flow 

2. 1. 1 Select Vehicle/Shop 

The Vehicle/Shoo Use Ca se be gins when the use r navigates to the Vehicle/Shop area of a 
reservation or ticket. This could be initiated at any point during the Reservation/Open Ticket 
process. 

2. 1.2 System displays the Select Vehicle, Loss Information and Select Shop Areas 

The system displays an area for the user to select and enter information about the renters 
vehicle. The fields displayed to the user are the following: 

• Year ( If the physical term inal location is in the U.K. and Ireland the system does not display 
this field.) 

• Make 

• Other Make 

• Model 

• Other Model 

• Color 

• Other Color 

• Registration Number (If the physical terminal location is in Europe the system displays this 
field. 

If the physical terminal location is in Germany the system also displays the following field to the 
user:,, 

• Class 

n M. 2 , 3. 4. 5. 6. 7. 8. 9.10) 

(The Legacy/ECARS 1 .0 system does not store the registration number or the "Schwackeiiste" 
Class in Germany.) 

If the physical terminal location is in Germany also displays the following fields to the user; 

• Vehicle Type 

• Number of Doors 

• Fuel Type 

• Engine Size 

• En gine Power 

• Class 

The system also displays an area for the user to enter and sfilfict loss information about the 
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vehicle. The fields displa yed to the user are the following: 

• is Car Drivable?: 
o (Blank) 

o Yes 
o Ng 

• Type of Loss: 
o (Blanks 

o Damage 
o Theft 

• Total Loss 
o (Blank) 
o Y§§ 

o N£ 

• Date of Loss 

» Theft Waiver Da ys (if the physical termin al location is in Europe the system does not display 
this field.) 
o (BlanlO 

o 1 Dav 
o 2 Davs 
o 3-Days 

The system also displays an area for the user to enter Notes about the Vehicle. 
The default values for the above fields is (Blank) 

The system displays an area for the user to select an account from the Branch Short List. JM 
system also gives the user the option to: 

Enter a Legacy Customer Numher. If the user chooses this option, the use case continues 

alternate flow Enter a Legacy Customer Number. 

Search for an Account If the user selects this o ption, the use case continues at alternate 
flow Search. 

Arid a "Note on File" Shoo to the reservat ion/open ticket If the user selects this option, the 
use* r.ase continues at alternate flow Add Not on File Account. 

2. 13 User Decides to Search for Year 

The user initiates a search for the year a ren ter's vehicle was manufactured. 

2.1.4 System Searches for Vehicle Year 

The system r etrieves and dis plays the list of years that a user may select from. _ 

2. 1 5 User Selects the Vehicle Year 

The user selects the year of t he renter's vehicle. 

2 16 System Searches for Make 

The system retriev es and displays the list of nossihle makes to choose from for the previously 

selected ( Vehicle^ year. 

2. 1 7 User Selects the Make 

The user selects the make of the renter's vehicle. The user can also choose to select "Other" 
and/or enter text in the "Other Make" field. 
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2.1.8 System Searches for Model 

The s ystem retrieves and display s the list of possible models to choose from for the previously 
selected make. 

2.1.9 User Selects the Model 

The user selects the model of the rente r's vehicle. The user can also choose to select "Other" 
and enter te xt in the "Othe r Model" field. If the physical terminal location is in Germany, the use 
case continues at Alternate Flow German Vehicle and Class Information . 

2.1.10 System displays Colors 

ThA system retrieves and displays the list of colors to choose from. 

2.1.11 User Selects the Color 

The user selects the color of the renter's vehicle. The user can also choose to select "Other" 
^t er text in the "O ther Color" field. 

2.1.12 User Enters the Vehicle Note 
The user enters a note about the renter's vehicle. 


.. User 


2.1.13 User Selects and Enters the Loss Information 
The user selects whether the car is drivable, the type(s) of loss and the date of loss. Ifthe user 
selects "Theft" as a type of loss the use case continues at alternate flow Tfeeft War 
Selects to display Branch Short List 

he user selects the option to display the hranch short list 

2. 1. 14 System displays Branch Short List 

The s ystem retrieves and dis plays the Bra nch Short list The columns that are displayed to the 
user are (from left to riahft. 
Account name 

Legacy Customer Number (called Accoi 
Account tvoe 

Owning Group and Branch 
Address 


State 


Phone Numbers 

If the physical terminal location is in Europe, the use case continues at Alternate Flow European 
Branch Short List 


2.1.15 User selects Account from Branch Short List 

The user selec ts an account from the list, if the user does not choose an accoi int from the list, 
the use case continues at alternate flow Search. 

2.1.16 System Displays Contacts 

The s ystem displays the list of Contacts for the se lected Account to the user along with 
"Unknown". (All Accounts hRve a listing nf "Unknown*™ a Contact) 
The column displ ayed to the use r will he the following: 
• Last Name 
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• First Name 

If there are_no Contacts identified for a particula r Account b esides "Unkn own", the use case 
continues at alternate flow No Contacts. 


2.1.17 Option to Select Contact or Add New Contact 

The user has the option to sele ct a contact from the list or add a New Contact 

2. 118 User Selects Contact 

The user sel ects a contact from the list. If the user chooses to add a new contact r the use case 
continues at alternate flow Add New Contact. 

2. 1. 19 User Selects to Exit the Vehicle/Shop Area 

The user selects to exit the Vehicle Area/Shoo. (From here, the user can navigate to anv other 
area within the Reservation/Open Ticket) 

2. 1.20 Validation of the Date of Loss and Theft Waiver Days 

The s ystem validates the value in the date of loss field. If a date of loss is not valid because: 

• The date does not exist (F ebruary 30) 

• The date is greater than today's date. 

the use case continues at alternate flow Invalid Date Value. $ 

2.1.21 End 

The use case ends. 
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2.2 Alternative Flows 

2.2.1 German Vehicle and Class Information 

2.2.1.1 The system retrieves and displa ys the list of Vehicle Types tha t a user mav select from for the 
previously selected model. 

2.2.1.2 The user sel ects the Type of the rent er's Vehicle. 

2.2.13 The system retrieves and displays the list of Number of Doors that a user mav select from for the 
previously selected Vehicle Type. 

2.2.1.4 The user selec ts the Number of Doors for the renter's vehicle. 

2.2.1.5 The system retrieves and displays the list of Fuels that a use r mav select from for the previously 
selected Number of Doors for the renters vehicle. 

2.2.1.6 The user selects the Fuel ty pe for the renter's vehicle. 

2.2.1.7 The system retrieves and displays the li st of Engine Sizes that a user mav select from for the 
previousl y selected Fuel typ e for the renter's vehicle. 

2.2.1.8 The user sel ects the Engin e Size for the renter's vehicie. ^ 

2.2.1.9 The system r etrieves and displays the list of Engine P owers that a user mav select from for the 
previously sele cted En gine Size for th e renter's vehicle. 

2.2.1.10 The user selects the Engine Power for the renter's vehicle. 

2.2.1.11 The system retrieves and displays the Qjgjj for the renter's vehicle. 

2.2.1.12 The use case continues at Svstem displays Colors in the basic flow. 

2.2.2 Theft Waiver Davs 

2.2.2.1 When the user selects "Theft" as a tvoe o f loss, the svstem enables the "Theft Waiver Davs" 
field. ~ " 

2.2.2.2 The user selects the n umber of the ft waiver davs. 

2.2.2.3 The use case returns to Us er Selects to Fyit the Vehicle/Shop Area in the basic flow. 

2.2.3 invalid Date Value 

2.2.3.1 The system displays a feedback mj§§jgj that the "Date is invalid". 

2.2.3.2 The svstem prompts t he user to correct the date. 

2.2.3.3 The user sel ects to correct the date and the use case r eturns to User Selects and Enters the 
Loss Information in the basic flow. 
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2.2.4 Euro pean B ranch Short List 

2.2.4.1 The s ystem retrieves and displays the European Bran ch short list ( NOTE: This list is comprised 
gfatl accounts that have an own ing Group that equals the Group of the physical terminal 
location.) The columns displayed to the user are : 

• Account Name 

• Account Number 

• Account Type 

• Owning Gro up/Branch 

• Address 

• QM 

• State 

• Zjfi 

• Phone Numbers. 

2.2.4.2 The user selects an account from the list that is displayed. 

2.2.4.3 The use case continues at User selects Account from Branch Short List in the basic flow. 


2.2.5 

2.2.5.1 The system displays an area with all the fields emptied out so that the user can enter search 
criteria. The fields th at are avaiiable are: t 

• Group. This in cludes an "All Groups" option. For reservation pilot, group will be 
limited to the physical location's group only. 

• Account Name 

• Account Ph one Number(s) 

• Account Tvoe. This includes an "All" option. (See Sp ecial Requirements for the list 
MvaJld Account Types) 

2.2.5.2 The user enters an Account Name and selects "All" as the Account Tvoe. 

2.2.5.3 The user init iates the search. 
2.2.5.4 


The system validates the search criteria. (If only an account type is entered, the system will 
prom pt the u ser that at least one other criterion must be selected. If only a group is chosen, the 
system will prompt the user that at least one other criterion must be selected.) 

2.2.5.5 The system c hecks the status of the search. If No Account Matches am found, the use case 
continues at alternate flow N o Account Matches. 

2.2.5.6 The s ystem displays the matches to the user in a sum mary list. The columns that are displayed 
to the user are: ffrom left to right) 

Account name 

Leoacv Customer Number (called Account Numher in ECARS 2.0) 
Account tvoe 

Gro u p and Branch 



Phone Nu mber(s) 
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2.2.5.7 The user has the following options: 

• Select an ac count from the summary list. 

• Clear the search criteria. 

• Search again. 

• Exit. 

2.2.5.8 If the user chooses to sele ct an accoun t from the sum mar y list, the use case continues at System 
Displays Contacts in the basic flow, if the user chooses to cl eaxih^s^ardicriteria, the use case 
continues at the first step in alternate flow Search. If the user chooses to search again, the use 
case contin ues at the first step in alt ernate flow Search. If the user c hooses to exit, the use case 
continues at System displays Branch Short List in the basic flow. 

2.2.6 Enter a Legacy Customer Number 

2.2.6.1 From the Basic Flow, the user chooses to enter a Legacy Customer Number. 

2.2.6.2 The user types in a Legacy Customer Number and initiates a search for all the information 
associated with the entered Legacy Customer Number. 

2.2.6.3 The system checks the s tatus of the search. If No Account Matches a m found, the use case 
continues at alternate flow No Account Matches. If More than one Account match is found, the 
use case continues at al ternate flow More Than One Account Match. If the search results in only 
one match, the use case continues at S ystem Displ ays Contacts in the basic flow. 


2.2.7 No Account Matches 

2.2.7.1 From the bas ic flow, the system displays a message to the user letting them know that No 
Account Matche s or record s were found. 

2.2.7.2 The use case continues at System displays the Select Vehicle. Loss Information and Select 
Shop Areas in the Basic Flow. 

2.2.8 More Than One Account Match 

2.2.8.1 The system displays a summary list of the matc hes to the user. The columns that will be 
displa yed in the summary list are ffrom left to right): 

• Account name 

• Legacy Customer Number 

• Account tvoe 

• Address 

• QM 

• State 

• Zic 

• Phone Number^ 

2.2.8.2 The user has the option t o select an ac count from the list or to exit. If the user selects an 
Account from the list, the use case continues at System Displa ys Contacts in the basic flow. If 
the user chooses to exit the list without selecting an A ccount, the use case continues at System 
displays Branch Short List in the basic flow. 
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2.2.9 Add Not on File Account 

2.2.9.1 The system displays an area for the user to enter Account information for an account that is not 
on file. The fields that must be entered are: 

• (Account) Name 

• (Street) Address 

• Phone Number 

• State 

• fie 

« Contact Last Name 

• Contact First Name 

2.2.9.2 The user enters the (Account) Name. (Street) Address. Zip/Postai Code and Phone Number. 

2.2.9.3 The system d ispla ys the option to search for the Citv and State/Province based upon the 
Zip/Postal Code and Country. 

2.2.9.4 The user selects the option and the system performs the search for the Citv and State/Province 
that match the Zip/Postal Code and Country. 

2.2.9.5 The s ystem produces a sinole Citv and State/Provin ce result and continues at the next step in 
the basic flow, if the search produces no matching City and State/Provincs information, the use 
case continues at alternate flow No Match to Zip/Postal Code . If the search produces multiple 
cities the use case continues at alternate flow Multiple Citv Results . 

2.2.9.6 The system populates the Citv and State/ Province fields. The system also makes the information 
in these fields available for edit. 

2.2.9.7 The system associates the Not on File account to the reservation/t icket and the use case 
continues at alternate flow Add New Contact, if the user chooses to exit, the use case continues 
at System Displays Contacts in the basic flow. 

2.2.9.8 The system associates the new contact added to the Account chosen and the use case 
continues at User Selects to Exit the Vehicle/Shoo Area in the basic flow. 

2.2.10 No Match to Zip/Postal Code 

2.2.10.1 The system displays a feed back messag e that the zip/p ostal code does not produce matching 
cit y and state/province information. 

2.2.10.2 The system prompts the user to manu all y enter ci t y and state/ province information. 

2.2.10.3 The user selects to ma nually ente r citv and sta te/ province information and the use case 
proceeds back to 2.2.9.7 in the alternate flow Add Not on File Account 

2.2.11 Multiple City Results 

2.2.11.1 The system d is plays a feedback message that the Z i p/Postal cod e produces more than one 
matching citv. 

2.2.11.2 The system displays the list of cities and prompts the user to select a Citv. 

2.2.11.3 The user selects a Citv from the list and the use case proceeds back to 2.2.9.7 in the alternate 
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flow Add Not on Fiie Account 


2.2.12 No Contacts 

2.2.12.1 From the basic flow, the system displays a message letting the user know that no contacts have 
been set up for this Account. (All Accounts have a listing of "Unknown" as a contact The 
message will display when "Unknown" is the only contact present) 

2.2.12.2 The user can either: 

• Add a new contact. 

• Select a c ontact of "Unknown" 
« 

2.2.12.3 if the user chooses to add a new contact, the use case continues at alternate flow Add New 
Contact, if the user selects a contact of "Unknown", the use case continues at User Selects to 
Exit the Vehicle/Shop Area in the Basic Flow. 

2.2.13 Add New Contact 

2.2.13.1 From the basic flow, the system displays an area for the user to enter Contact information. Ihg 
fields that must be entered are: 

• Last Name 

And/or 

• First Name * 

2.2.13.2 The user ent ers a first and/or last name and accepts the new contact information entered. Jf 
the user chooses to exit, the use case continues at System Displays Contacts in the basic flow. 

2.2.13.3 The system a ssociates the new contact added to the Account chosen and the use case 
continues at User Selects to Exit the Renter's Ve hicle/Shoo Area in the basic flow. 

3. Special Requirements -Vehicle/ Sho p Use Case 

1) Year. Make and Model domain values come fr om the database. 

2) The list of years that the r enter's vehicle was manufac tured will be listed in descending 
order. 

3) The note entered into the Veh icle Notes field should be viewable from the Vehicle Notes 
section of the Vehicle/Shop screen. Th e y WILL NOT be viewable from the Notes screen/use 
case.. 

4) A contact m ust be selected for every A ccount that is select as a Shop. NOTE: This is a not a 
re quirement for a re servation only open ticket. 

5) The valid Account Types th at are displayed to the user in Search are: 
o Body Shoo 

o Corporate 
c Government 
o Fleet 
o Dealership 
o Insurance 
o Other 

6) The Branch Short List is currently beino generated fr om the existing Legacy system and 
is bein g store d in a table on the Oracle database. 

7) The system should not sear ch or display fo r anv deactivated or deleted accounts. 
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8) The user must have the ability to cancel a search at anv time du ring the search. 

9) The Navigation Bar for the Vehicle /Shop area should disp lay the following: 

a. Line 1: Year. Make and Model of the Renter's Vehicle 

b. Line 2: Shoo Account Name 

10) Notes should be generated when anv of the following events occur: 


The user adds a 

"Mnt on Filp" 
iMUi ui i rue 

contact. 

Not on file contact "First Name Last 
Name" was added for Account 

1 iQI 1 Iv VVClw QUUvU Ivl riWWVilK 

"XXXXX" 

Create/Edit 

Create (if data exists from 
the reservation) /Edit 

Vehicle/Shop 

The user changes 
me snop account. 

Shop "XXXX" was changed to 

"YYYY" 

Edit 

Create (if data exists from 
the reservation} /Edit 

Vehicle/Shop 

The user chanqes 
the type of loss. 

Type of loss "XXXX" was changed 
to "XXXX". 

Edit 

Create (if data exists from 
the reservation) /Edit 

Vehicle/Shop 

The user changes 
th#*Total Loss?" 

1 otai loss aaaa was cnangeu xo 
"XXXX". 

Edit 

Pr<aate (if Hata PYi<ste frnm 

OICdLC ^11 UCuCl CAIOlg It will 

the reservation) /Edit 

Vehicle/Shop 

Thb4iser chanqes 
the^date of loss. 

Date of loss "XXXXXX" was 

^,, nna j t— ii vy YYYY" 

cnangea to aaaaaa . 

Edit 

Create (if data exists from 

tho roc<ar\/afri/^n^ /FHit 

Vehicle/Shop 

TNMjser changes 
number of theft 
wafer days. 

Theft waiver days "X" was changed 
to "X" 

Edit 

Create (if data exists from 
the reservation) /Edit 

Vehicle/Shop 

ThMjser changes 
^renter's vehicle 
Year. 

The renter's vehicle Year "XXXX" 
was changed to Year "XXXX". 

Edit 

t 

Edit 

Vehicle/Shop 

Thbkjser chances 
thllienter's vehicle 

The renter's vehicle Make "XXXX" 
was changed to Make "XXXX" 

Edit 

Edit 

Vehicle/Shop 

Thiluser chanqes 
thcienter's vehicle 
Model. 

The renter's vehicle Model "XXXX" 
was changed to Model "XXXX" 

Edit 

Edit 

Vehicle/Shop 

The user changes 
the renter's vehicle 
Other Make text. 

The renter's vehicle other Make 
"XXXX" was changed to "XXXX" 

Edit 

Edit 

Vehicle/Shop 

The user chanqes 
the renter's vehicle 
Other Model text. 

I ne renters venicie otner Mooei 
"XXXX" was changed to "XXXX" 

Edit 

Edit 

Vehicle/Shop 

The user chances 

number of the 
renter's vehicle, (if 
the ohvsical 
terminal location is 
in Europe. 

The renter's vehicle registration 
number was "XXXX" was changed 
to "XXXX". 

Edit 

Edit 

Vehicle/Shop 

The user chances 
the class of the 
renter's vehicle. (If 
the ohvsical 
terminal location is 
in Europe.} 

The renter's vehicle class "X" was 
changed to "X". 

Edit 

Edit 

Vehicle/Shop 
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Edit Reservation 
Shoo Area Fields 
Account Name 

If the account name is changed (to a valid acc ount ), account number will change _ 
appropriately and the contact name will now be "select". 

Account Number 

If the account number is ch anged, the account name will change appropriately and the 
contact name will now be "select". 

Contact Name 

There are no edit rules for open ticket on cha nging or deleting a contact name. 
Phone Number 

There are no edit rules for open ticket on chang ing or deleting a phone number. 

Vehicle Area Fields 

Year 

There are no edit rules for o pen ticket on changing or deleting a Year 
Make 

If a Make is changed or deleted, the Model field will be cleared. * 
Model 

There are no edit rules f or open ticket on changing or deleting a Model. 
Other Make. Other Model. Other Color 

There are no edit rules fo r o pen ticket on changing or deleting an Other Make. Other Model 
Other Color. 

Loss Information Area Fields 

Is Car Drivable?. Type of Loss . Total Loss?. Date of Loss, and Theft Waiver Davs 

There are no edit rules for open ticket on changing or deleting Is Car Driva ble?. Type of Loss. 
Total Loss? T Date of Loss, and Th eft Waiver Davs. 


4. Pre-Conditions 

• A user is authorized through a login process to create or edit a reservation or ticket. 

• The user has accessed a reservation or ticket, either in the process of editing or creating. 

5. Post-Conditions 

6. Questions 
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Updates to Use Case 
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1.2 

The changes made are: 

• The dependencies between options were removed. 

• Pick-up location is a free form text area 

• Start charges by typing in a day was changed to 1 
character entrv onlv 

• Airport Information Scoped for pilot 

• System Generated directions scoped for pilot 

• For pick-up time, the user must be able to also see 
how many reservations are booked during each 
half hour for the selected pick-up date. * 

• Mileage is coined -*o charge for mileage or 
limited free mileage. 

• Start charges if different now includes a date and 
TIME. Notjustadate. 

M. Pallia 
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1.3 

Removed all references to start/end charges date 

James Atteberry 
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Use Case Specification: Reservation with Dates 

1. Reservation with Dates 
1.1 Brief Description 

This use case describes the interactions a user makes with the system to determine what day and time, 
where, and how a customer will be come into Enterprise. 

2, Flow of Events 

2.1.1 The system displays an a rea with the following options : 

Sorted from most commonly entered options to least commonly entered. 

• Enter a Pick Up Date and Time . If the user chooses this option, the use case continues 
in the basic flow 

• Select a Pick u p Method . If a pick up method is selected, the use case continues at 
alternative flow (Pick Up Method) 

• Pick-up location . If the user chooses to identify a pick-up location, the use case 
continues at alternate (Pick-up Location). 

• Take Directions . If take directions is selected, the use case continues at alternate 
(Directions). 

• Chanoe P/U or Return Location . If the user elects to change pickup or return location, 
the use case initiates the Change P/U or Return Location use case. 

• Enter Package Specials . The use case continues at alternative flow (Package Specials). 

• Air port information . If the user chooses this option, the use case continues at alternate 
(Airport Info). 

• Enter a Retur n Date and Time . if a Return date is entered, the use case continues at 
alternative flow (Add Return Date and Time) 

• Enter a Drop Charge If a Drop Charge is entered, the use case continues at alternate 

(Add a Drop Fee) 

2.12 The s ystem provides the fo llowin g options to the user for selecting pick up date and time : 

• Manually enterin g the date and time . 

• Usin g a calendar function to select a date . The use case continues at alternative flow 
(calendar function) 

• Selecting a ti me from a list o f 3Q-mlnute time increments . The use case continues at 
alternative flow (Pick-up time - 30-minute increments) 

2 1.3 The system ch ecks the date entered . If the date ente red is less than the current date or more 
than 13 months in the future , the use case continues at alternative flow (Invalid Pick Up Date). If the 
date entered is not a valid date (i.e. February 30) the use case continues at alternative flow (Invalid 
nate^ if the Pick Up date is a~da y that the b ranch is closed , the use case continues at alternative flow 
(Branch h™ *r* \ if the Pick-up date is prior to the current date , the use case continues at alternate 
(Invalid Date). 

2 1 4 The system checks the time entered . if the time is invalid , the use case continues at alternative 
flow (Invalid Time), if the time is outside of the branch's operating hours , the use case continues at 
alternative flow (Branch Hours). NOTE- the user will not be allowed to enter a time until a date has been 
entered. 

2.1.5 The user has the following options 

• Choose another option from 2. 1 . 1 of the basic flow. 
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• Complete Reservation 

• Save and Continue . if the user chooses to Save and Continue, the use case continues at 
alternative flow (Save and Continue) 

• Navigate to anv other area within reservation . The system initiates the Reservation 
Navigation Use Case. 

(Note: User has the option to save to the database and continue from place saved anytime after 
(2.1.2) of the basic flow.) 

2.1.6 The use case ends. 

2.2 Alternative Flows 

2.2.1 invalid Pick Up Date 

2.2.1.1 The system displays a feedback message that the Date is invalid . 

2.2.1.2 The system prompts the user to correct the values that are invalid . 

2.2.1 .3 The user enters the correct values and the use case continues at (2.1.3) of the basic flow. 

2.2.2 invalid Return Date 

2.2.2.1 The s ystem dis plays a fe edback message that the Date is invalid . 

2.2.2.2 The system prompts the user to correct the values that aj^lnvajjd . 

2.2.2.3 The user enters the correct values and the use case continues at (2.2.7) of the alternate flow 
(Return Date and Time). 

2.2.3 invalid Date 

2.2.3.1 The system displays a feedback message that the Date is invalid . 

2.2.3.2 The system prompts the user to correct the values that are invalid . 

2.2.3.3 The user enters the correct values and the use case continues at (2.13) of the basic flow. 

2.2.4 invalid Time 

2.2.4.1 The system displays a feed back message that the Time is invalid . 

2.2.4.2 The s ystem p rompts the user to correct the values that are invalid . 

2.2.5 Branch Hours 

2.2.5.1 Thft system displays a feedback message that the branch is closed. 

2.2.5.2 The user is given the option to s elect a different fimj nr the user can co n t inue. 

2 2 5 3 If the user chooses to continue, the system will accept the values and the use case continues at 
(2. 1 . 1 ) of the basic flow. If the user chooses to select another time, the use case will continue at (2. 1 .4) 
of the basic flow. 

2.2.6 Add Return Date and Time 

2.2.6.1 From the basic flow, the user decided to enter a Return 
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2.2.6.2 The sy stem provides the following options to the user for selectin g return date and time: 

• Manually entering the date and time. 

• Using a calendar function to select a date. The use case continues at alternative flow 
(calendar function) 

• Selecting a time from a list of 15-m inute time increments. The use case continues at 
alternative flow M5-minute increments) 

2.2.6.3 The system checks date entered. If the date entered is less than the current date or more than 
13 months in the future, the use case continues at alternative flow (Invalid Return Date). If the date 
entered is not a valid date (i.e. February 30) the use case continues at alternative flow (Invalid Date). If 
the Pick Up date is a day that the branch is closed, the use case continues at alternative flow (Branch 
Hours). 

2.2.6.4 The system checks the time entered. If the time is invalid, the use case continues at alternative 
flow (Invalid Time). If the time is outside of the branch's operating hours, the use case continues at 
alternative flow (Branch Hours). If a time is entered but no date is entered, the use case continues at 
alternative flow (Time with No Date) 

2.2.6.5 The use case continues at (2.1 .5) within the basic flow 

2.2.7 Calendar Function 

2.Z7. 1 From the basic flow or Return Date alternate, the system w ill display a calendar control to the 
user according the HT ML standard a lread y impl emented. * 

2.2.7.2 The user sele cts the date 

2.2.7.3 The system populates the date and the use case continues at the exact spot from which thev 
came. 

2.2.8 Plnk-un Time - 30-Minute Increments 

2.2.8.1 From the basic flow, the user choo ses to select a 30-minute Interval from a list 

2.2.8.2 The system d is plays a table to the user that has the following information: 

• A list of times in 30-rninu tes intervals for one 24-hour period cued uo to the first half hour 
interval of the physical location's operating hours for the chosen pick-up date. For example, 
if the branch opens at 7:30 am on the date that is selected the list should cue up to the 
7:30 interval On the other hand, if th e branch open s at 7:15am. the list should cue up to 
7:0Q am. (NOTE: The user must be able to select any 30-minute interval within one 24- 
hour period). 

And 

• The total number of reservations for each 30-minu te interval during the date selected as the 
pick-up dat e. The rese rvation count does not include voided reservations. 

(MOTE' the system must differentia te the time intervals that are not within the operating business 
hours of the terminal's physical location^ 

2.2.8.3 The user s elects a 30-minute interval from the list , If the da te the user selects is a dav the 
branch islios ed or if the branch has no ho urs of operatic^ defined, the system will cue up to 7:00am . If 
the interval is outside of the branch's operating hours, the use case continues at alternate (Branch 
Hours). If the Pick-up date and Return date are the same and the return time is prior to the pick-up time, 
the use case continues at alternate (Invalid time) 

2.2.8.4 The use case continues at (2.1 .5) within the basic flow. 
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2.2.9 15-Minute i ncrements 

2.2.9.1 From the Alternate (Return Date and T ime) and alt ernate (Package Specials!, the user chooses 
to select a 15-minut e interval from a list. 

2.2.9.2 A list of times in 15-minutes interval s for one 24 -hour period cued up to the first half hour interval 
of the physic al location' s operating hours for the chosen pick-up date. For example, if the branch opens 
at 7:30 am on the date that is selected, the list should cue up to the 7:30 interval. On the other hand, if 
the branch opens at 7:15am, the list should cue up to 7:00 a m. If the bra nch is closed or there are no 
hours listed for a particular location, the list should cue up to 7:00am (NOTE: The user must be able to 
select anv 15-minute interval within one 24-hou r period). 

(NOTE: the syste m must differentiate the tim e intervals that are not within the operating business 
hours of the terminal's p hysical location) 

2.2.9.3 The user selects a 15-minute interval from the list. If the interval is outside of the branch's 
operating hours, the use case continues at alternate (Branch Hours). If the Pick-up date and Return date 
are the same and the return time is prior to the pick-up time, the use case continues at alternate (Invalid 
time) 

2.2.9.4 The use case continues at (2.1 .5) within the basic flow. 
2.3 Dro p Fee 

2.3.1 The user selects to add a drop fee for the return location of a reservation. * 

2.3.2 The syste m will allow the user to enter a drop fee. 

2.3.3 The user e nters the drop fee and the use case continues at ( ) in the basic flow. 


2.3.4 Package Specials 

2.3.4.1 From the basic flow, the user choose tQ add a special rate package. 

(NOTE - If the u ser wants to add a Package s pecial, t he user must first select a billing tvoe^ 

2.3.4.2 The system displa ys an are a for the user to enter the following: 

• Start date 

• Start time 

• End date 

• End time 

• Package Amount or Per Dav amount 

• Free Miles or Miles per dav 

• Additional Mileage Fee 

2.3.4.3 The user enters a start date, start time end date and end time manually in to the area provided. 
If the user chooses the calendar function to enter a d ate, the use case continues at alternate (calendar 
functionV If the user sel ects a time from the 3Q-mi nute intervals provided, the use case continues gt 
alternate (30 minute increments) 

2.3.4.4 The system checks the dates and times entered by the user, if any of the following occur, the 
use case continues at eith er alternate (inv alid dateV alternate (invalid time) or alternate (Time no Date): 

• A time and no date is chosen 

♦ A start date prior to the current dav 
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• A start date prior to the Pick-up date 

• An end date after the return date 

• An end date prior to th e pick-up or start date 

• if the start date and the end date are the same date. 

If the user picks a date or time outside of the branch's operating hours, the use case continues at 
alternate (Branch Hours) 

2.3.4.5 The s ystem provides the user with the follow ing option: 

• Enter a package amount nr a per day amount 

2.3.4.6 The User enters an amount for the pack age in the area provided. If the user chooses to enter a 
per da y amount, the use c ase continues at alternate f Per Day Special! 

2.3.4.7 The s ystem provides an area to determine the amoun t of miies allowed for the package and 
gives the user the o ption t o choose No Charge for M iles or specify a limited amnunt of free miles. 

2.3.4.8 The user selects No Charge for Miles, if the users chooses to specify limited free mileage, the 
use case continues at alternate (Limited Mileage Package) 

2.3.4.9 The use case continues at (2.1 .5) within the main flow. 

2.3.5 Per Day Special 

2.3.5.1 From the alternate ^Packag e S pecialV the system displays an area for the user to enter a per day 
rate and chose either No Charge fo r Miles or limited free miles. * 

2 3.5.2 The user types in a per day rate and chooses No Charge for Miles for the mileage, if the user 
chooses limited free miles, the use case continues at alternate (limited mileage per day special). 

2.3.5.3 The system validates the rate and the mileage choice. The system retains the entered 
information and the use case continues at (2.1 .5) within the basic flow. 

2.3.6 Limited Mileage Package 

2.3.6.1 From the alternate Package Specials, the system provides an area for the user to enter the 
following i nformation: 

• Mileage per package 

• Amount for over mileage 

2.3.6.2 The system validates the mileage entered and the dollar amount entered. The system retains 
the data entered and the use case continues at (2.15) within the basic flow. 

2.3.7 < Smiled Mileage Per Day Special 

2.37.1 From the alter nate (Per Dav S pecial^ the system provides an area for the user to enter the 
following i nformation: 

• Mileage per da y durin g the special 

• Amount for over mileage 

2.3.7.2 The system validates the mileage entered and the dollar amount entered. The system retains 
the data entered and the use case continues at (2.15) within the basic flow. 

2.3.8 Pink Up Method 

2.3.8.1 From the basi c flow, the syste m dis plays an area for the user to select a nick-un method. The 
values available to the user are: 
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• Mn 

• DM 

• Del/R 

2.3.8.2 The user selects walk-in as the pick-up method. If the user selects P/Up, Del, CWC or Del/R, the 
use case continues at alternate (Pick-up Location), otherwise, the use case continues at (2.1.5) within the 
basic flow. 

2.3.9 Pick U p Location 

2.3.9.1 From the alternate fPick- up Methodl the system provides an a rea for the user to manually enter 
a oick-uo location in a free form text field. 

2.3.9.2 The user enters a location 

2.3.9.3 The system retains the information that was entered and provides the user the following options: 

Enter Directions - If the user chooses this option, the us e case continues at alternate 
(Directions). 

Select another option. The use case con tinues at (2.1 .5^ within the basic flow. 

2.3.10 Airport Information 

2.3.10.1 From the basic flow, the system displays the following fields to be entered by the user when the 
Pick up location selected is Airport: 

• Airline Name 

• Fli ght Number 

• Arrival Time 

2.3.10.2 The user enters the information and the use case continues at (2.1.5) of the basic flow. 

2.3.11 Directions 

2.3.11.1 From alternative flow (Pick up location) or the basic flow, the system will provide an area to 
either enter directions or, if a pick-up location has been chosen, the system will determine the directions. 
If the user chooses system-generated directions, the use case continues at alternate (system-generated 
directions). 

2.3.1 1 .2 The user types in the directions in a free text area. 

2.3.1 1 .3 The system retains the directions. 

2.3.1 1 .4 The use case continues at (2.1 .5) within the basic flow. 

2.3.12 System generated directions (Future scope! 

2.3.12.1 The system ch ecks the pick up location and determines if there is enough information to 
generate directions. 

2.3.12.2 The system generates the drivin g direc tions from the physical terminal's location to the pick-up 
location selected bv the user. 

2.3.12.3 The system display* the directions to the user and the use case continues at (2.1 .5) within the 
basic flow. 

2.3.13 Cancel 
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2.3. 1 3. 1 Get from HTML standards document************* 

2.3.14 Complete Reservation 

2.3. 1 4. 1 Get from HTML standards document************* 

2.3.15 Save and Continue 

2.3. 1 5. 1 Get from HTML standards document************* 
3. Special Requirements - Reservation Dates 

• The user mav kev in a oick up time or select a pick up time from a list of time periods in 30- 
minute intervals, within branch operating hours. A time may not be selected without a valid date. 


4. 


5. 


User must be able to navigate to anv other panels within the application. 
The user m a y only det ermine one discount per reservation 

Pre-Conditions 

The system must have successfully initiated the Create Reservation Use Case. 
Post-Conditions 


! fi 1 Notes should be aenerated when the followina events take place : 

i w — — — 

Event 

Note Text 

When to generate 

The Reservation Pick-up date is changed 

? 

Pick-up Date "XX/XX/XXXX" was changed to 
"XX/XX/XXXX" 

Edit 

TheAeservation Pick-up time is chansed 

Pick-up Time "XX: XX" was changed to "XX: XX" 

Edit 

The&eservation pick-up method is changed 

Pick-up Method "XX" was changed to "XX". 

Edit 

TheSteservation pick-up location is chanaed 

Pick-up Location "XXXX" was changed to "XXXXX" 

Edit 

Thelteservation Return date is changed 

Return Date "XX/XX/XXXX" was changed to "XX/XX/XXXX" 

Edit j 

The Reservation Return time is changed 

Return Time "XX: XX" was changed to "XX: XX" 

Edit 

The Reservation return method is changed 

Return Method "XX" was changed to "XX". 

Edit 


7. Extension Points 

8. Future Scope 

9. Q's 

1. When coming in from create reservation, if no pick up date has been entered and no date is 
entered in the dates section, will the system default to the current date or leave the pick up 
date blank? 

2. Does the user have to select a method, location and directions or can the user enter any of 
the following independently? 
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Use Case Specification: Discounts and Products Pilot 

1- Discounts and Products Pilot 
1.1 Brief Description 

This use case describes the interactions between the user and the system when the user has decided to 
either manually select a discount, the user has selected a Rate Source that has a discount identified 
within the special instructions or the user wants to enter a rate for a product. 

2. Flow of Events 

2.1 Basic Flow 

2.1.1 The use case begins when the user has either selected a rate source within the Rates Use case, 
has decided to manually add a discount to a reservation or enter a per day rate for CDW or 
PAI/PEC. If the user has selected a Rate Source, the use case continues at alternate (Rate 
Source Discount). If the user has decided to manually enter a discount, the use case continues 
in the basic flow. If the user has decided to enter a per day rate for CDW or PAI/PEC, the use 
case continues at alternate (Add Products). 

2.1.2 The system displays an area for the us er to enter a discount percentage amount . 

2.1.3 The user enters a percentage discount (Example, if a user enters an 8. it will be considered 8%) 

2.1.4 The system checks the amount entered . If the amount entered exceeds 50. the system displays 
a message to the user that a discount ca nnot exceed 50% . 

2.1.5 The system retains the am ount entered 

2.1.6 The user can navigate to any other pa rt of the reservation and the system initiates the 
Reservation Navigation Use Case. (No te: the user should have the ability to navigate at any time 
within this flow! 

2. 1 .7 The use case ends 

2.2 Alternative Flows 

2.2.1 Rate Source 

2.2. 1 . 1 From the basic flow, the user has selected a rate source that has a discount. DW or PAI/PEC 
identified with in the special instructions . If the rate source does not have a discount, DW or 
PAI/PEC identified, the use case continues at (2.1.1) within the basic flow. If the rate source 
does have DW, PAI/PEC or both identified, the use case continues at alternate (Rate Source 
Products). 

2.2.1.2 The system populates the discount determined into the perc enta ge disc ount area and gives the 
user the option to change or remove this discount . If the user chooses to change or remove the 
discount, the use case continues at (2.1.2) within the basic flow. 

2.2.1.3 The user can navigate to anv other part of the reservation and the sys tem initiates the 
Reservation Navigation Use Case . (Note: the user should have the ability to navigate at any 
time within this flow) 

2.2.2 Rate Source Products 

2.2.2.1 From the alternate (Rate Source), the system p opulates the a mounts for DW. PAI/PEC or both 
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determined bv Special Instructions into the DW or PA1/PEC area and provide the user the option 
to chance or remove the products . if the user chooses to change or remove the products, the 
use case continues at (2.2.3) within the basic flow. 

2.2.2.2 The user can navigate to anv other part of the reservation and the system initiates the 

Reservation Navigatio n Use Case . (Note: the user should have the ability to navigate at any 
time within this flow) 

2.2.3 Add Products 

2.2.3.1 From the basic flow, the user has decided to enter a rate for a product. 

2.2.3.2 The system displays an area where the user can ente r a per dav rate for DW or PAI/PEC . 

2.2.3.3 The user enters rates for DW or PAI/PEC . (Note: The user can enter either of these within a 
reservation). 

2.2.3.4 From here, the user can navigate to anv other part of the reservation and the system initiates the 
Reservation Navigation Use Case . 

2.2.3.5 The use case ends 

3. Special Requirements 

• In Germany, it is against the law to show that a discount was applied p a rate and to print the 


4. 

5. 

6. 


discount. 
Future Scope 

Pre-Conditions 

The user must have initiated the Create Reservation use case. 
System Generated Notes - Produ cts and Discounts 


Event 

Note Text 

When to generate 

The user changes anv of the values within the products 

What values were changed and what the old and 
new values are. 

Create (If the products are 
auto-populated) /Edit 

area . 


7. Post-Conditions 

8. Extension Points 

9. Questions 
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Use Case Specification: Reservation Number Fast 

Path 

1. Reservation Number Fast Path 
1.1 Brief Description 

1.1.1 This use case describes how the user interacts with a system to search for and locate a 

reservation that is displayed in edit/view mode, using Fast Path. The use case shows the flow of 
events that occur when conducting a Fast Path Search. The system will search for, locate and 
display, in edit/view mode, a reservation based on an exact match of the reservation number 
entered by the user. 

2. Flow of Events 
2.1 Basic Flow 

2.1.1 The use case begins when a user chooses to search for a reservation. 

2.1.2 The user e nters a reservation number in the Reservatio n Number field . The system searches for 
an exact m atch on the number entered . 

2.1.3 The system initiates the Search Engine Use Case using the reservation number entered. The 
system searches for an exact match on the text starting from the first position in the field 

2.1 .4 The system receives the appropriate processing information from the Search Engine use case. If 
the search returned no records, the use case continues at alternate flow (No Matches). If the 
search returned more than one record, the use case continues at alternate flow (Multiple 
Matches). If the search has exceeded the time allotted, the use case continues at alternate flow 
(Time Out). Otherwise, the use case continues along the main flow. 

2.1 .5 The system initiates the Edit/View use case to displays the details of the reservation to the user. 

Note: From within the Edit/View use case, the user can perform the follow ing options : 

• If the user chooses to pri nt the reservation , the use case continues at alternate flow (Print the 
Reservation Details). 

• If the user chooses to edit the reservation , the reservation continues at alternate flow (Edit a 
Reservation). 

2. 1 .6 The use case ends. 
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2.2 Afternative Flows 

2.2.1 No Matches 


2.2.1.1 From the basic flow (2.1.5), the system prompts the user that there were no records that matched 
the reservat ion number entered . Once the user acknowledges the prompt, the use case 
continues at (2.1 1 ) of the basic flow. 

2.2.2 Multiple Matches 

2.2.2.1 From the basic flow (2.1 .4). the use case displays the results of the search according to the 
Default Sort Order (defined in the Search Reservation use case): 

• Pick up Gro up (ascending). Concatenate pick uo g roup and branch. 

• Pick up Bra nch (ascending) 

• Date (ascending) 

• Time (ascending) 

• Renter Name (ascending) (Last name. First name) This is format that renter name will display in 
the summary list 

• Pick Up Method 

• Car Class 

• Reservation Ty pe 

• Reservation Number 

2.2.2.2 Sort order for Date and Time Headers: 

• Reservations with a date but no time. 

• Reservations with a date and time. 

• Reservati ons with no date but have a time. 

• Reservations with no d ate and no t ime. 

2.2.3 The user selects a single reservation to edit/view from the list of reservation matches displayed. 

2.2.4 The s ystem initiates the Ed iWiew use case to displa ys the details of the reservation to the user. 

Note: From within the Edit/View use case, the user can perform the following options: 

• If the user chooses to print the reservation, the use case continues at alternate flow (Print the 
Reservation Details). 

• If the user chooses to edit the reservation, the reservation continues at alternate flow (Edit a 
Reservation). 

2.2.5 Time Out. 

2.2.5.1 The system d isplays a m essage to the user that the time allotted to search has been exceeded. 

2.2.5.2 The system prompts the user to choos e one of the following options: 

• Quit the search and display none of the matches so far. Then the use case ends. 

• Quit the search and display the matches found so far. 

• Continue searching. 
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2.2.5.3 If the user chooses to quit the search and not display the matches, the use case continues at 
(2.1.1) in the basic flow. If the user elects to quit the search and display the matches found, the 
use case continues at (2.1 .4) of the Multiple Matches Alternative flow. If the user elects to 
continue the search, the use case continues at (2.1.3) of the basic flow. 

3. Special Requirements 
3.1 < First Special Requirement > 

4. Pre-Conditions 


4.1 The user has successfully logged onto the system. 

5. Post-Conditions 

6. Extension Points 

7. FAQ 


* 
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Use Case Specification: Reservation Forecasting 

1. Reservation Forecasting 

1.1 Brief Description 

This use case will describe the interactions between the system and a user when the user wants 
to view the total number of reservations per day over a two-week period. 

2. Flow of Events 

2.1 Basic Flow 

2.1 .1 The use case begins when the system determines the group and branch number using the 
terminal's physical location and the local date and time. If the user changes the location, the use case 
continues at alternate (Change location). 

2.1.2 The system retrieves the total number of reservations for each dav with in the 14-dav period, 
determined bv the user, where the reservation pick-up date equals a dav with in the 14-d ay period . If the 
user enters no date, the system will default the 14-dav period to the current date and includ e the 13-davs 
following the current date. (NOTE- the system will not retrieve any re servations that have a status of 
void) 

2.13 The system displays: 

• The Month. Dav and Year of the First Dav with in the 14-dav period. 

• The Month. Dav and Year of the Last Dav with in the 14-day period. 

• A table showing the total number of reservations for each dav within the 14-dav period. 

• The Month. Dav and Dav of the week for each dav within the Table. 

2.1.4 The user has the option to do one of the following: 

• View the list of reservations for a sp ecific day within the 14-day period. 

• Move forward to the next 14-day period (if applicable) 

• Move backward to the previous 14-dav period (if a pplicable) 

• Enter a different start date 

• Refresh 

• Exit 

If the user chooses to view the list of reservations for a specific day within the 14-day period, 
the use case continues at alternate (Reservation List). If the user chooses to move forward 
to the next 14-day period, the use case continues at alternate (Next). If the user chooses to 
move to the previous 14-day period, the use case continues at alternate (Previous). If the 
user enters a different start date, the use case continues at alternate (Different Date). If the 
user chooses to Exit, the use case continues at (2.1 .5) in the basic flow. 

2.15 The use case ends 

2.2 Alternative Flows 

2.2.1 Next 
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2.2.11 From the basic flow, the user wiil want to view the number of reservations per dav for the next 
14-dav period. 

2.2.1.2 The system determines the next 14-dav period. (The Next 14 dav period includes the LAST dav 
of the current 14-dav period and the 13 davs in the future to that dav.) 

2.2.1 .3 The use case continues at (2.1.2) in the basic flow. 

2.2.2 Previous 

2.2.2.1 From the b asic flow, the user will want to view th e number of reservation s per dav for the 
previous 14-dav period. 

2.2.2.2 The system determines the previous 14-day period. (A Previous 14 dav period includes the 
FIRST dav of the current 14-dav period and the 13 davs prior to that dav.) 

2.2.2.3 The use case continues at (2.1.2) in the basic flow 

2.2.3 Chan ge Location 

2.2.3.1 From the basic flow, the user has the option to change the location: Here are the different 
combinations a user may_s.elect: 

• Same Group (as the terminal's physical location) and a different Branch with in that group 
These will be available after the pilot of reservation 

• Same Group (as the terminal's physical location) and all Branches with in that group. 

• Different Group and a different Branch with in that Group 

• Different Group and All branches within that Group 

2.2.4 The user selects the branc h drop down list. 

2.2.5 The system will display the rental branches for the group, defaulting to the curren t location. 

2.2.6 The user selec ts a branch from the drop down list. 

2.2.7 The system will displa y a view of the selecte d branch's total number of reservations. 

***As soon as the limitations of the Peoolesoft H ierarchy are amended, the user should have the option to 
select anv level within the Enterprise Branch H ierarchy and ail the levels below the selected level. This 
hierarchy includes: B ranch. Are a T City, Reg ion and Group. 
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2.2.7.1 The System uses the new group and branch number selected as the location until the iocation is 
changed aga in. The use case contin ues at 12 A .2) in the basic flow. 

2.2.8 Reservation List 

2.2.8.1 From the basic flow, the user wants to see a list of the reser vations with a oick-up date that 
equals the dav selected within the 14-dav period. 

2.2.8.2 The system initiates the Daily Activity Use Case. 

2.2.9 Different Date 

2.2.9.1 From the basic flow, the user will want to view a 14 -day period starting on a particular date. The 
user can enter this date manually or use a calendar control to select the date. 

2.2.9.2 The system uses the date selected as the First dav of the 14-dav period. The use case 
continues at (2.1.2 ) in the basic flow. 

2.2.10 Refresh 

2.2. 1 0. 1 From the basic flow, the user chooses to refresh. 

2.2.10.2 The system uses the current date: the group and branch selected and determines the 14-dav 
period . The use case continues at (2.1 .2) in the basic flow. 

3. Reservation Forecasting UC Special Requirements 

1 . The user should be able to enter a date manually or select a date from a calendar control. 

4. European Requirements 

5. Pre-Conditions 

1. The user has successfully logged in 

6. Post-Conditions 

7. Extension Points 

8. J&M Q's 
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Use Case Specification: Reservation Notification 

(ARMS/UK Call Center) 


1. Reservation Notification (ARMS/UK Call Center* 
1 .1 Brief Description 

1.1.1 This use case defines the notification system that will alert a user when an "urgent" type 
reservation exists within the system. The use case will also describe the interactions a user must 
take to satisfy the notification. 

2. Flow of Events 
2.1 Basic Flow 

2.11 The use case begins as soon as the user successfully logs onto the ECARS 2.0 Browser. 

2.1.2 The system is aware that notification type reservations exist for the default terminal location . The 
first 2 types of reservations that will receive a notification are: 

• Any reservation with th at was cre ated within the ARMS system (North America^ 

• Anv reservat ion that was created at a UK Call Center (Europe) The UK Call C enter Group and 
Branch Numbe r is UK9Z 

If the default terminal location is in Europe, the use case continues at alternate (UK Call Center) 

(NOTE: For this iteration, UK9Z is the only branch, but more branches or other reservation types will 
eventually be added to this notification system. 

2.13 The system determin es the stat us of EACH notification type reservation. 

A) For North America, the status of EACH reservation will be determined bv one of the following: 

• If the reservation is an ARMS origin type and has NOT been edited/viewed bv the user, the 
reservation status is "Not Contacted" 

• If the reservation is an ARMS orig in type and has been edited/viewed but the user was 
UNABLE to contact t he renter, the reservatio n status is "Contact Attempted" 

• If the reservation is an ARMS origin ty pe and has been edited/viewed but the user was ABLE 
to contact th e renter, th e reservation status is "Contacted" 

(NOTE: Within the EdiWiew use case, the user will determine whether the status of the reservation is 
"Contact Attempted" or "Contacted.") 

2.14 )f more that O NE notification type re servation exists, here are the multiple reservation 
possibilities: 

• One or more of the reservations have a status of "N ot Contacte d" AND ope o r more of the 
reservations have a status of "Contact Attempted". If this is the case, the use case continues at 
alternate (Not Contacted and Contact Attempted^ 

• All of the reservations hav e a status of "Contacted". If t his is the case, the use case continues at 


alternate (AN Contacted^ 


• One or more of the reservations have a status of "Contact Attempted" AND NONE of the 
reservations have a status of "Not Contacted". If this is the case, the use case continues at 
alternate (Contact Attempted) 

• One or more of the reserva tions have a status of "Not C ontacted". If this is the case, the use 
case continues w ithin the basic flow. 
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2.1.5 The system displays a notification to the user that at least one of the reservations has a status of 
"Not Contacted" . The notification should b e visible enough to draw im mediate attention. (Almost 
to the point o f annovin p the user.^ 

2. 1 .6 The user can acknowledge the notification or not acknowledge the notification . If the user does 
not acknowledge the notification, the use case continues at alternate (Not Contacted - Not 
Acknowledged). 

The system retrieves and displays a summary list of the reservations that caused the notification, he 
summary list should be displayed in the order in the table below Pick-up Date G Pick-up Time G Renter 
Name □ Bill- To Account Name DReservation Creation Date** ^Reservation C reation Time** 
□Reservation Number 

The sorting should be done using this method: 

• Status -'Not Contacted" followed by "Contact Attempted" 

• Pick-up Date - ascending 

• Pick-up Time - ascending 

• Center's Nam e ascending 


NOTE— Sort order for Pick-up date and time is as 

• Reservations with a date but no time. 

• Reservations with a date and time. 

• Reservations with no date but have a time. 

• Reservatio ns with no date and no time. 

* 

NOTE — Reservations with a status of "Contacted" will NOT be dis played in this summary list. 

**These fields are the cr eation date and time when Legacy added it to the database. NO Ij&famjte 
reservation was added to the Oracle database. 

2.1.7 The user has the option to do one or more of the following: 

• EdiWiew a r eservation in the list 

• Print the list 

• Print the details of a reservation in the list 

• Exit 

If the user chooses to print the list, the use case continues at alternate (Print). If the user chooses to print 
the details of a reservation in the list, the use case continues at alternate (Print the Reservation Details). 
If the user chooses to exit the summary list, the use case continues at (2. 1 .3) in the Basic Flow. If the 
user chooses to edit/view, the use case continues. 

2.1.8 The s ystem initiates the edit/view us e case 

2. 1 .9 The use case continues at 2.1 .2 in the basic flow 
2-2 Alternate Workflows 

2.2.1 UK Call Center 

2.2.1.1 The system determines the s tatus of EACH notification type reservation. 

A) For Europe, the status of EACH reservation will be determined b y one of the following : 

• If the reservation was created bv the UK Call Center and has NOT been edited/viewed. 
The reservation status is "Not Contacted" 

• If the reservation was created bv the UK Call Center and has been edited/viewed but the 
user was UNABLE t o contact th e renter, the reservation s tatus is "Contact Attempted" 

• If the reservation was created bv the UK C all Center and has been edited/viewed but the 

Confidential ©<Company Name>, 2000 Page 5 


<Project Name> 

Version: <1.0> 

Use Case Specification: <Use-Case Name> 

Date: <dd/mmm/yy> 

<document identified 


user was ABLE to cont act the renter, the reservation status is "Contacted" 
(NOTE: Within the Edit/View use case, the user will determine whether the status of the reservation is 
"Contact Attempted" or "Contacted: 1 ) 

2.2.1 .2 The system has determined the status of each reservation and the use case continues at (2.1 .4) 
in the basic flow. 


2.2.2 All Contacted 

2.2.2. 1 From the basic flow, when the system has ALL reservations that have a status of "Contacted", 
the system will not display anv visible notification to the user . The use case continues at (2.1 .2) 
in the basic flow. 

2.2.3 Contact Attempted 

2.2.3. 1 From the basic flow, when the system finds at least one reservation with a status of "contact 
attempted" and no reservations with a status of "Not Cont acted", the s ystem will display a visible 
notification to the user. This notification will be less outstanding to the user than the notification 
used for a "Not Contacte d" reservation . (NOTE: The user must also be able to differentiate this 
notification from the notification used for a "Not Contacted" reservation) 

2.2.3.2 The user ca n acknowledge the notifica tion or not acknowledge the notification . If the user does 
not acknowledge the notification, the use case continues at alternate (Contact Attempted-Not 
Acknowledged). Otherwise, the use case continues at (2.1.6) in the basic flow. 

2.2.4 Print 

2.2.4.1 From the basic flow , the use case includes the Print Reservation Use case . Otherwise, the user 
can select to do another option at (2. 1 .7) in the basic flow or the use case continues at (2. 1 .9) in 
the basic flow. 

2.2.5 Print the Re servation Details 

2.2.5.1 From the basic flow, the system in itiates the EditA/iew use case and the user can select to print 
the reservation details from there . Otherwise, the user can select to do another option at (2.1.7) 
in the basic flow or the use case continues at (2.1 .9) in the basic flow. 

2.2.6 Not Contacted - Not A cknowledged 

2.2.6.1 From the basic flow, the system will continue to display the "Not Contacted" notification to the 

user until the user acknowledges the notification . When the user acknowledges the notification, 
the use case continues at (2.1.6) in the basic flow. 

2.2.7 Contact Attempted - No t Acknowledged 

2.2.7.1 From the basic flow, the system will continue to displa y the " Contact Attempted" notification to the 
user until the user ackn owledges the notification . When the user acknowledges the notification, 
the use case continues at (2.1 .6) in the basic flow. 

2.2.8 Not Contacted and Contact Attempted 

2.2.8.1 From the basic flow, the system displays the "Not Contacted" notification to the user . 

2.2.8.2 The user can acknowledge the notification or not acknowledge the notification. If the user does 
not acknowledge the notification, the use case continues at alternate (Not Contacted -Not 
Acknowledged). Otherwise, the use case continues at (2.1 .6) in the basic flow. 
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3. Special Requirements - Reservation Notification UC 

• The notification should alert the user as close to real time as nnssihte 

4. Pre-Conditions 

• The user has successfully logged onto the ECARS 2.0 Application 

5. Post-Conditions 

6. Extension Points 

7. FAQ 
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Use Case Specification: Daily Reservation Summary 


m 

m 


1. Daiiv Reser vation Summary 
1.1 Brief Description 

The pickup summary screen is a summary view of the day's reservations for a particular branch. The 
user will be able to see at a glance the number of reservations the branch has during 30 minute time 
period, how many of each pick up method for those reservations and how many of each car class for the 
reservations in the summary. 

2. Flow of Events 

2.1 Basic Flow 

2.1.1 This use case is initiated when the user elects to view the Pick Up Summary panel. 

2.1.2 The s ystem e stablishes currant date and time for the terminal's physical location. 

2.1.3 The system establishes currant group and branch for the terminal's physical location. 

P 214 The s ystem retrieves all daily reservations th at match the default group/branch for the date and 

"H time enual to th e hranrh's current local date and time . If the system retrieves no reservations, the use 

W case continues at alternate flow (No Records). 

U 2.1.5 The system displays the Pick I Ip Summary tahle The system displays to the user the results 

pj according to the following headers and sort order for the default group and branch. 

Kl The system displa ys a summary table to the user with the following column headers: 

pi • Time (prese nted in 30. minute increments) 

p • Pick Up method (Deliverv/Pick Up/ Walk-In) 

j»t • Car Class 

2.1.6 The system dis plays the Pick Hp Summary tahle in the following sort order: 

. Time (ascending In an-miniite increments. 

• Mo nick up time entered shown at the too of the list. 

• No pick up da te entered shown at the bottom of the list. 

2.1.7 The information in the summary will be pr esented to the user so the user can obtain the following 
information at a glance: 

• The Pick Up S ummary will show at a nlance. how many resen/ations there are in each half hour 
time period. 

• From the Pick Up Summary how many of each car cla ss is scheduled to go out per half hour 
time period. (Note: car classes shown a re only the ones found on the reservations retrieved. 
The onl y car classes displayed are the ones retrieved from reservations Car classes not 
retrieved bv the system are not displayed.) 

. From this sum mar y the user will he able to see how manv of each identified nick up method is 

scheduled for a time period. 
. From this summa ry the user will he able to distinguish newly created reservations from existing 

reservations. 
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2.1.8 The system will display reservations so all reservations with a Dick up time equal to the current 
date are displayed without scrolling. 

The user will be able to se e all reservat ion summarie s without scrolling up and down or side to side, 
including all reservations with that have a pick up date equal to the current date but no pick up time 
entered on the reservation. 

*A new reservation is one that: 

• Natres reservations that are sent durin g the current day. 

• ARMS res ervations sent during the current dav. 

• Branch reservations that are created during the current for the current dav. 

• Reservations that are tr ansferred from another bra nch for the current dav. 

• Reservations that are moved from anothe r dav to the current dav within the same branch. 

• Reservation for the current dav that's time has been changed during the current day. 

• Reservation that has a cre ation date equal to the current date. 

2.1.9 The user can perform the following options: 

• The user chooses to view the list form of the reserv ations for a particular time, the use case 
continues at alternate flow (View Reservation List fo r a Selected Time) 

• The user chooses to refresh the list, the use case continues at alternate flow {Refresh V 

• The user can change location. The use case continues at alternate (Change Location) 

2.1.10 The use case ends. * 
2.2 Alternative Flows 

2.2.1 No Records 

2.2.1.1 The system displays a zero results list display and the use case continues,- 

2.2.2 View Reservation List for a Selected Time 

2.2.2.1 The user choo ses to view the expanded list form for a reservation or group of reservations in a 
chosen time block. 

2.2.2.2 The user clicks on the time he wishes to view rese rvations for in the Pick Up summary. 

2.2.2.3 The system checks the time selected and retri eves the default group/branch reservations that 
have a pickup time equal to the time selected. 

2.2.2.4 This use case includes the Daily Activity use case with the selected starting time. 

2.2.3 Refresh 

2.2.3.1 The system can be manually refreshed bv the user and checks the branch's nurrent local date 

and time then retrieves and displays anv new reservations* that hav^ a creation date equal to the 
hranch's current local date. These new reservations will display in a manner that make them 
distinguishable from the other reservations already in the list 
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2.2.4 Chan ge Location 

2.2.4.1 From the main flow, the user can change location. They can change either the group and branch 
or just the branch within the same group. For Reservation pilot th e user will be able to only change the 
Branch. 

2.2.5 The user selects the bra nch drop down list from th e summary screen . 

2.2.6 The system will display the rental branches for the croup, defaulting to the current location . 

2.2.7 The user selects a branch from the d ro p down list. 

2.2.8 The system will display a view of the selected branch's summary data and the use case continues 
at (2.1 .4) in the basic flow using the entered branch as the current branch. 

2.2.9 Change Date 

2.2.9.1 From the main flow, the user changes the start da te of the summary list . Once the user selects 
a new date, the use case continues at (2.1 .4) in the basic flow using the entered date as the default date. 

3. Special Requirements -Reservatio n Summary UC 

1. The user can click on a time in the Pick Up Sum mary and "hyperlink" to the expanded Daily 
Reservation list for the time selected . ^ 

2. As in Search Reservation use cas e. Column Headers are sortable. 

3. T ypes of reservations not shown in the default group/bra nch daily reservation list are as follows: 

o Voided reservations. 

o Reservations transferred to another branch. 

o Reservations that have been attached to an open ticket . 

4. The total number of reservations fo r the day should be displayed in the Pick Up Summary . 

5 Refresh will be manual refresh. Business does not want re fresh to interrupt work in an application. 
Should not refresh while scrolling through a reservation list. S hould not refresh so as to be noticeable 
b y the user while working in an application 

6 Refresh will also occur automatically when the user leaves th e Daily reservation list then returns to 
the list . 

7. A newlv created reservation is anv res ervation with a creation date equal to the local current date . 

4. Pre-Conditions 

• The user has successfully logged onto the system. 

5. Post-Conditions 

6. Extension Points 

7. Important Questions for Jon and Mary 
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Use Case Specification: Search Reservation 


1. Search Reservation 

1.1 Brief Description 

This use case will describe how a user interacts with a system to search for and locate a 
reservation. It will show the flow of events that occur when a search is conducted to locate a 
reservation. The system will search for and locate a reservation (or more than one reservation) 
based on the search criteria entered by a user 

2. Flow of Events 
2.1 Basic Flow 

2.1 . 1 The use case begins when the user chooses to search for a reservation. 

2.1.2 The system defaults the loc ation to the Group and Branch number w here the use r logged in. {If 
the user changes location, the use case continues at alternate flow (Change Location)}. 

2.13 The system displays all search criteria fields emp tied out, all o wing the user to enter specific search 
criteria as can be seen in Table's A and B. 


Table A 

* • 

Table B 

These options are the most commonly 

These options are the less frequent options: 

selected. 



■ A customer name (Bill-to. Referral, or 1 

■ Driver's Last Name 

Shop) 

■ Driver's First Name ( First name can 

■ A customer number (Bill-to. Referral 

onlv be used as a search criteria in 

or Shot)) 

conjunction with Last name) 

■ Claim Number/Pol/Po No. (this is 

* Phone number (anv nhone number 

currently one field) 

associated with the driver) 

* A Ranee of Pick-un Dates ("from' 1 to 

■ Reservation Number 

"to") 


■ Date reservation taken 


• Registration Number of Renter' s 


vehicle (this will not be used in N. 


(Note: The current group branch location 

(Note: The current stoud branch location 


always disnlavs) 



2.1.4 The user enters a renter's last name. The system searches for a mat ch on the text T starting from 
the first position in the field. (There is an implied wildcard at the end o f the character set entered but no 
leading or imbedded wildcards within the character set). 
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2. 1 .5 The use case can continue at alternate flows (Range of Pick Up Dates through Registration 
Number of Renters Vehicle). The use case can be read at any of these alternate flows (a user is most 
likely to search by the criteria in Table A more often than the criteria identified in Table B). 

2.16 (Note: The user should not be allowed to start a search until one of t he search criteria has been 
entered.) 

2.1.7 The system initiates the search engine use case using the criteria entered by the user. The system 
receives the appropriate processing information from the Search Engine use case. 

2.1.8 The system checks the status of the search. If the search has returned more than n records, the 
use case continues at alternate flow (Too Many Records). If the search returned no records, the use 
case continues at alternate flow (No Matches). If the search has exceeded the time allotted, the use case 
continues at alternate flow (Time Out). Otherwise, the use case continues along the main flow. 

2.1.9 The system d isplays the results of the search r accordin g to the Defa ult Sort Order (2.3). in 
summary list form to the user. 

2.1.10 The user can perform the following options: 

• If the user chooses to print the list , the use case continues at alternate flow (Print the List). 

• if the user elects to print the details of a rese rvation from the list , the use case continues at 
alternate flow (Print the Reservation Details). 

• if the user picks a reser vation from t he list to edit/view , the use case continues at alternate flow 
(Edit/View a Reservation). 

2.1.11 The use case ends 

2.2 Alternate Workflows 

2.2.1 Change Location 

2.2.1.1 The user is allowed to ch ange location de pendant upon his level of security . See security 
document. 

2.2.1.2 From the basic flow (2.1 .2), the user can change location by changing the Group and Branch 
number, or the user can chance location bv chang ing just the Branch number . (Note: the user can also 
select to search "ALL" Group numbers and "ALL" Branches within a specific Group number. 

2.2.2 The user s elects the branch drop down list. 

2.2.3 The system will display the rental branche s for the croup defaulting to the current location. 

2.2.4 The user sel ects a branch from the dron down list and the use case continues at (2.1.3) in the 
basic flow. 

2.2.5 Too Many Records 

2.2.5.1 From the basic flow (2.1.8), the system h as returned more records than the governor allows. 
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2.2.5.2 The system displays the first series of records applying default sort order (2.3). UC2.20 The 
system a lso displays: 

• Total number of records found. 

• The system displays a range of records for the series . 

• The system displays the ability to navigate t o the next se ries of records.fif 
applicable) 

• The ability to navigate to the previo us series of records.fif applicable) 

2.2.5.3 The user ha s the option to do the following: 

• View the next series of records . 

• View the previous series of records. 

• Print the list of the current series or print the reservation details or edit/view a 
reservation from the list . 

• Search again. 

2.2.5.4 If the user chooses to view the next series (if app licabiel th e use case c ontinues at (Too Many 
Isf Records) . If the user chooses t o view the previous serie s (if ap plicable), the use case continues at (Too 
Id Many Records). If the user ch ooses to pri nt the list of the current series or print the reservation details 
L:f or edit/view a reservation from the list, the use case continues at (2.1.10) in the basic flow . If the user 
S chooses to s earch aoain. th e use case continues at (2.1 .3) in the basic flow . Otherwise, the use case 
H continues at ( 2.111) in the basic flow. # 

y 2.2.6 UC2.6 Time Out 

*. 2.2.6.1 The system d isplays a message to the user that the time allotted to search has been exceeded. 

Q 2.2.7 No Matches 

fU 2.2.7.1 From the basic flow (2.1.61 the system wil l present a message to the user that no records were 

f|1 found for the criteria entered and show a 0 for the total number of records found. . 

F? 2.2.8 Print the List 

2.2.8.1 From the basic flow (2.1.7.1), the system initiates the Print Use Case Specification Document. 
The use case continues at (2.1 .10) of the basic flow. 

2.2.9 Print the Reservation Details 

2.2.9.1 From the basic flow (2.1 .7.2), the system initiates the Print Use Case Specification Document. 
The use case continues at (2.1 .10) of the basic flow. 
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2.2.10 Edit/View a Reservation 

2.2.1 0.1 From the basic flow (2.1 .7.3), the system initiates the Edit/View Reservation Use Case 
Specification Document. The use case continues at (2.1.10) of the basic flow. 

2.2.11 Search by P ick Up Date Ranae 

2.2.11.1 The user ch ooses to search for a reservation(s) bv e ntering the Range of Pick-up Dates on the 
reservation. 

2.2.11.2 If the user only enters a "from" date, the system wil l default the "to" date to the same dav that 
was entered. 

2.2.11.3 The system validates that the "from" date must be less than or equal to the "To" date 

2.2. 1 1 .4 The system will prompt t he user if a nv of the valid ations are n ot correct , otherwise, the use 
case continues at (2.1.6) in the basic flow. 

2.2.12 Search by Date Reservation Created 

2.2.12.1 The user cho oses to search for a reserv ations bv ent ering the date the reservation was 
created. 

2.2.12.2 The sy ste m searches for a reservat ion b y the e ntered reservation creation date. 

2.2.1 2.3 The use case continues at (2.1 .7) in the basic flow. 

2.2.13 Search bv a Customer Number 

2.2.13.1 The user enters a specific custom er number. 

2.2.1 3.2 It has been decided that we will not narrow Customer Number Search by shop, bill-to or referral. 
The search will search the Bill-To and Shoo fields ONLY on the re servation and a reservation that 
contains a match on any of the 2 fields will be returned. 

2.2.1 3.3 The use case continues at (2.1 .6) in the basic flow. 

2.2.14 Search bv an Account Name 

2.2.14.1 The user enters an Account Name. The system searches for a match on the text, starting from 
the first position in the field . (There is an implied wildcard at the end of the character set entered but no 
leading or imbedded wildcards with in the character set) . 

2.2.14.2 The search will search the Bill-To and S hop fields ONLY on the reservation and a reservation 
that contains a match o n an y of the 3 fields will be returned 

2.2.14.3 The use case continues at (2.1.6) in the basic flow. 

2.2.15 Search bv a Renter Phon e Number /any phone number associated with the Renter! 

2.2.15.1 The user enters a renter pho ne number, (The number entered must be the full number 
including area code. 1 ) 

2.2.15.2 The system searches for a reservation with an y matchi n g renter p hone number regardless of 
the phone number type (Home. Office. Other). (Match must be exact: no wildcard search.) 
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2.2.16 Search bv Claim/Pol/Po No. The user enters either a Claim/Poi/Fo No. in the Claim/Fol/Po 
field . 

2.2.17 The user enters a Claim/Pol/Po No.. The system searches for a match on the text, starting from 
the first position in the field. (There is an im plied wildcard at the end of the character set entered but no 
leadin g or imbedded wild cards withi n the character set) . 

2.2.17.1 The use case continues at (2.16) in the basic flow. 

2.2.18 Search bv R enter's Vehic le Re gistration Number/L icense Plate Number 

2.2.18.1 The user enters a Registration Number/License Plate Number of the Renter's Vehicle . 

2.2.18.2 The system searches for a match on the text, applying from left to right on the number of 
characters for a reservatio n bv the entered Registration Number/License Plate Number of the Renter's 

2.2.18.3 The use case continues at (2.1.6) in the basic flow. 

2.2.19 Search by Renter's First Name 

2.2.19.1 The user enters a renter's first name. The system searches for a match on the text, starting 
from the first position in the field. (There is an implied wildcard at the end of the character set entered 
but no leading or imbedded wildcards within the character set). (Note: First name field is disabled until a 
valid value is entered in the last name field). 

2.2.19.2 The use case continues at 2.1.5 of the basic flow. 

2.3 Default Sor t Order and Column Headers. 

• This is the list of columns to display in the summary list and its sort priority for the first 4 
columns: 

• Pick up Group (ascending) Concate nate pick up group and branch. 

• Pick up Branch (ascending) 

• Date (ascending) 

• Time (ascending) 

• Renter Nam e (ascending) (Last name. First name ) This is the format that renter name 
will display in the summary list. 

• Pick U p Method 

• Car Class 

• Reservation Typ e 

• Reservation Number 
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2.3.1 Search hv Reservation Number 

2.3.1.1 The user ent ers a reservation number. 

2.3. 1 .2 The system initiates the Search Engine use case using the reservation number entered. 

2.3.1.3 The s ystem s earches for an exact match on the numh sr entered starting from the first position in 
the field. 

2.3.1 .4 The system receives the appropriate processing information from the Search Engine use case. 

2.3.1.5 The use case displays the results of the search accordinn to the default sort order and column 
headers. 

3. Special Requirements- Reservatio n Search UC 

3 o Any Hate entered bv a us er must have a month dav and year . The date search PdX will be one 
editable box . The search bv date will also display a calendar . 

3 3 For the oick u p date range the TO" date will he deactivated until a "From" date is entered . AfigLI 
"From" date is entered the "To" date will default to the "Fmm" date entered . 

3.4 Per our 4/3 meeting with Jon and Mary, Car class search was deleted from search res criteria. 

3.5 Per our 4/5 meeting with Jon and Mary. There will be a link embedded in the Renter Name Column 
Header of the Summary list that when cli cked on will take vou into the reservation. 

3 6 Per our 4/5 meeting with Jon and Mary. It was decided that on the search panel, the Customer 
Search Header would be called Account. The field Labels will he Account Name and Customer Number, 
The two fields will have radio buttons in fr ont of them and upon initial presentation neither option will be 
selected. 

4. Pre-Conditions 

4.1 The user has successfully logged onto the system 

5. Post-Conditions 

6. Extension Points 

7. FAQ 
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Use Case Specification: Reservation Home> 

1. Reservation Home 
1 .1 Brief Description 

This use case describes the flow a user takes when interacting with the reservation planning use cases. 

2. Flow of Events 

2.1 Basic Flow 

2.1.1 The use case begins when the user successfully Ioqs onto the ECARS 2.0 Reservation Browser. 

2.1 .2 The system initiates the Daily Activity Use Case 

2.13 Primarily, the user will o nl y view th e displa yed data and ev entually the data will be manually 
refreshed . Purina this time, the user must also have the ability to select other options as well. The 
options available to the user are: 

• Search for a reservation. The use case conti nues at alternate (Reser vation Search) 

• Forecast Re servation. The use case co ntinues at alternate (Reservation Forecast) 

• Edit a Reserva tion bv entering a Reservation Number. The use case continues at alternate 
(Reservation Fast Path) 

• Pick-up Summary. The use case continues at alternate (Pick-up Summary ) 

• Create a Rese rvation (Not Developed Y et), The use case continues at afternate (Create a 
Reservation) 

• Get a Rate (Not Developed Yet). The use case continues at alternate (Get a Rate) 

• ARMS/UK Call Center list. The use case continues at alternate (ARMS/UK Call Center ) 

2.1 .4 The user refreshes the data and the use case continues at (2. 1 .2) in the basic flow. Otherwise, the 
use case ends. 

2.2 Alternative Flows 

2.2.1 Reservation Search 

2.2.1.1 From the ba sic flow, the user mav not be able to find the reserva tion they are looking for. The 
user will se lect the option to sea rch for a reservation. 

2.2.1 .2 The system initiates the Reservation Search Use Case. 

2.2.2 Reservation Forecast 

2.2.2.1 From the basic flow, the user will want to see how many res ervations have been made for a 
particular dav or series of d avs in the near future. The user will select the option to view Reservation 
Forecasting. 

2.2.2.2 The system initiates the Forecast Reservation use case. 

2.2.3 Reservation Fast Path 

2.2.3.1 From the basic flow, the user has a reservation number they would like to make chances to. 
Instead of using the search function, the user enters th e reservation number into the edit reservation field. 

2.2.3.2 The system initiates the Reservation Fast Path use case. 
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2.2.4 Pick Up Summary 

2.2.4.1 From the ba sic flow, some branches will find the daily activity list is too detailed or difficult to use 
because of the large amou nt of reservations the branch has to manage. The user will opt to use the Pick 
U p Summary instead of the Daily Activity List. 

2.2.4.2 The system initiates the Pick-Up Summary use case. (Note-When the user changes to the pick- 
up summary view rather than the Daily Activity. 

2.2.5 Create a reservation 

2.2.5.1 From the basic flow, the user will have a customer that needs to make a reservation. The user 
will choose to create a new reservation 

2.2.5.2 The system i nitiates the Create Reserv ation Use case. 

2.2.6 Get a rate 

2.2.6.1 From the basic flow, the user will need the ability to get a rate for a customer. The user will 
select the option to get a rate. 

2.2.6.2 The system initiates the Get a Rate use case 

2.2.7 ARMS/UK Call Center 

2.2.7.1 The user ha s the ability to access the ARMS reserv ation list from the Reservation Home. The 


3. Special Requirements 

4. European Requirements 

5. Pre-Conditions 

6. Post-Conditions 

7. Extension Points 

8. J&M Q's 
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Use Case Specification: Transfer Reservation 


1. Transfer Reservation 
1.1 Brief Description 

This use case will describe how a user interacts with a system to change the location of a reservation. It 
will show the flow of events that occur when a reservation changes location. 

2. Flow of Events 

2-1 Basic Flow 

2.1.1 The use case begins when the user has the o ption to chance t he pick uo location or the return 
location of a reservation. If the return location is selected see alternate flow (Change Return Location) 

2.1.2 The user mav only change branch locat ion for the reservation . (Hate: The Pick up croup and 
branch will default to the c urrent location.) 

2.1.3 The user selects the br anch drop do wn list for the pick up location field. 

2.1.4 The system will display the rental branches for the croup T defaulting tn the current location . (Note: 
The Group drop down list will only show the rental branches for the group of the physical location.) 

2.15 The user chooses a branch from the drop down list. 

2.1.6 The system dis plays the fo llowing read only branch information: 

• Branch address 

• Davs of normal operation 

The user conftaraifa fiim^ an d has the opportunity to reselect. 

2.1.7 The system validates the pick uo date a nd time of the existing reservation to the selected branch . 
(Note: If the user selects a day and time that the branch is not open, use case continues at alternate 
flow, Date/Time Not Open.) 

2.1.8 The system will display a message to the user that the rates of the new location mav be different . 

2.1.9 The user initiates the change of nick up location . 

2.1.10 The s ystem w ill print the r eservation at the new location and the use case ends. 
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2.2 Alternative Flows 

2.3 Change Return Branch 

2.3.1 The user has the op tion t o change the return locatio n of a reservation . 

2.3.2 The user selects the bra nch drop down list for the return location field. 

2.3.3 The system will display the rental branches for the g roup, defaulting to the current location . 
(Note: The Group drop down list will only show the group of the physical location.) 

2.3.4 The user selects a branch from the drop down list . 

2.3.5 The system displays the following read only branch information : 

• Branch address 

• Phone number 

• Davsoi norm al operation 

• Hours of normal operation 
The user confir ms the branch bv selecting or canceling and has the opportunity to reselect. 

3 2.3.6 The system validates the return date and time of the existing reservation to the selected branch . 
J (Note: if the user selects a day and time that the branch is not open, use case continues at alternate 

3 flow, Date/Time Not Open.) 

.3 

2.3.7 The user initiates the change of pick up location. t 

2.3.8 The system will print the reservation at the new location and the use case ends. 

* 2.3.9 The user has the option to enter a drop fee for the returning location (see Dates and Rates use 
J case) otherwise use case ends. (Note: The user may choose to change the Pick up Location and Return 
I Location for the same reservation.) 

1 

I 2.4 nate/Time Not Open 

2.4.1 The user selects to change location to a hiannh on the date and time that the selected branch is 

2.4.2 The system will display a fee dback message that "The entered value occurs outside of normal 
hranrh hours Continue?" 

2.4.3 The system will display the dates or times entered that are outside of normal branch days and 
times. 

2.4.4 The user has the option to change the date and/or time or let the values remain as entered . 

3. Natres Reservation 

1. The branch cannotiraiis^QN arres Reservation . only Natres can access these reservations. 

2. The system will recognize this is a Nati onal Reservation and the transfer capability will beabled, 

4. ARMS Reservation 

1 . The branch can transfer an ARMS Reservation to anothe r branch within the group. 

2. The ARMS indicator will transfer with the reservation. 
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5. System Notes 

2. The user selects the Pick-up Location field and the previously entered location is changed , a system note 
will be generated when the user se lects to save the reservation. The following information will be 
captured: 

• Date and t ime that the change was made . 

• Employee n umber an d name that made the change. 

• What text in the locati on field was changed from and to. 

3. The user selects the Return L ocation field and the previously entered locati o n is changed, a system no t e 
will be gen erated when the user sel ects to save the reservation. The following information will be 
captured: 

• Date and ti me that the change was made 

• Employee number and name that made th e change . 

• What text in the location field was changed from and to 

6. Special Requirements 

General Rule Sets 

1. Any branch within the sam e group can perform any function on a reservation as if it is their own 
reservation . 

2. Changing outside of group for full release only (Based on Security). 

3. The branch drop down list only displays the bran ches for the defaulted group . 

4. The drop down list of bran ches will be lis ted in ascending order . 

7. Internationa! Requirements 

ARMS does not exist Internationally for pilot. 

• The transfer functionality is the sam e for UK as for U.S. 

• Will need worldwide transfer capability for full release. (Based on Security) 

The transfer fu ncti onalitv is the same for Germany as for U.S. 
Will need worldwide transfer capability for full release. (Based on Security) 


Ireland 
Canada 


The transfe r functionali ty is the same for Ireland as for U.S. 

Will need worldwide transfer capability for full release. (Based on Security) 

The transfer functionality is the same for Canada as for U.S. 

Will need worldwide transfer capability for full release. (Based on Security) 


8. Pre-Conditions 

A user is authorized through a login process to access the panel that is necessary to change the 
location of a reservation. 

9. Post-Conditions 

10. Extension Points 

11. Questions 

1 . What is going to be the authority for transferring from group to group for 
full release? Unknown at this time. 

2. Is there security around creating a new reservation for another branch? 
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No security check at this time, will remain the same as legacy. 

3. Should the rates of the new branch appear or be updated upon 
transferring the reservation or should a message be displayed for full 
release? A message should display for pilot that rates may be different. 

4. How are we going to handle call centers needing the ability to transfer 
from group to group for pilot? (ARMS) No group to group for pilot, will 
have to for full release. 

5. Should the branch information window display every time or give the 
user the option to view it? Branch info. Window will only be displayed if 
user opts for it to be displayed. 

6. Should there be a message displayed when transferring a reservation that 
the rates may change for the new location? A message does need to be 
displayed for pilot. 

7. Does there need to be an alert message to the transfer branch to alert 
them of the newly transferred reservation? An alert message does need 
to be displayed for pilot. 

i 
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Data elements need to be added at agreement level to vary YD fee charges. 

73 

Ancillary Charges 
(iteration 4) 
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Ancillary charges are location related charges that are not included in products or packages. Ancillary charge values are not 
set or maintained by specific contract provisions. The ancillary charge service utilizes rental parameters to identify 
appropriate ancillary charges. VRS currently implements Young Driver fees, Additional Driver fees, and After Hours fees 
as ancillary charges. Fuel price determination will be added to the ancillary charge service in order to enable a client 
application to retrieve, and modify fuel prices prior to creating detailed charges with the Charge Engine. 


The ancillary charge service design is based predominantly on the existing VRS ancillary charge logic. Ancillary charge 
gaps / requirements were not included in the initial business requirements document or the gap analysis. As a result, the 
initial design effort for the ancillary charges focused on documenting current functionality in order to facilitate determining 
ERAC's actual requirement for processing ancillary charges. Based on a review of the draft design issues and assumptions, 
further requirements have evolved and are reflected in this design. 

(Note: 1. The iteration 2 implementation of ancillary charges will not be fully functional and will only process ancillary 
charges for retail cases, hence, handling of contract conditions will not be functionally implemented until iteration 4. Since 

Hafter hour fees are based predominantly on contractual values, the after hours fee design will be not be implemented in 

□iteration 2 and will be revised for iteration 4. Areas of this design that are not being implemented until future iterations 

Ohave been grayed out.) 

Hi 

jjjl.l Dependencies 

**! 

h JDependencies with ERAC's Test windows etc. 

Si 

SJ 1.2 Data Conversion 

ill 

CPS 2, 

W "High level impacts to Data Conversion. A separate document will be published for data conversion design. 

ri 

"1.3 Impact Analysis 


The most substantial impact of the ancillary charge design is the relationship that exists between the Ancillary Charge 
Engine and the Charge Engine. The ancillary charge engine determines specific charges based on rental parameters. The 
link to, the charge engine is through the client application, where the client application can utilize the ancillary charge data 
as elements of the input parameters for the charge engine. 
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2 AnciUary Charge Sery^ 



2.1 Process Overview/Flow 


The ancillary charge service determines and formats specific additional charges for a rental transaction based on the rental 
parameters. The following fees are calculated by the service: 

~ Young drivers: The age of the driver is compared with age limits established within the UDA hierarchy for 



driver would be subject to young driver fees in addition to the additional driver fees. 


• Fuel Prices: The service will find the most appropriate fuel prices based on the UDA hierarchy and desired fuel 



Jp.2 Detailed Design Description 


{■* The ancillary charge service is currently implemented in VRS as a combination of Pro*C and PL/SQL that is called from a 
user exit from Oracle forms. In order to enable the service to be scalable, the ancillary charge service will be implemented 
as a Tuxedo service. It will provide the calling process as output a list of ancillary charges, suitable for client approval and 
incorporation into the charge engine input parameters. The calling process will be able to adjust the rate and unit values as 
needed prior to passing them into the charge engine. 

The service will either calculate each individual fee, or it will utilize input values for the specific fees as provided by the 
calling process. For example, if the calling process were to specify a Young driver Fee of $10.00, the service would not 
attempt to calculate or validate the young driver fee. It would accept the value and would then format the fee and prepare it 
for processing by the charge engine. Alternatively, if the calling process did not specify a Young driver Fee value, the 
service would determine the fee based on the station's fee and/or contractual override data. 

2.3 Database Table Impacts 

The initial porting of VRS elements for this project did not include the database tables needed to support ancillary charge 
processing. Subsequently, the ancillary charge tables have been added to the baseline database. In order to support the 
specific ERAC ancillary charge requirements some modifications to the baseline tables will be required. 
Four specific tables will need to be added to the database. Calculation of young driver fees requires the addition both the 
MIN_AGE_RSTRS and YOUNG_RNT_OVR tables. Additional driver fees are contained in ADDL_DVR_FEES and 
after-hours rental fees are contained in the STNS_SCHEDS table. 
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(note: STNS_SCHEDS contains data about station(branch) operating hours which is probably duplicated in the 
OFC_DIR__BR table in the ECARS Data Model.) 


Table Name 

High Level Description of Changes 

DDL Req Form § 

MIN_AGE_RSTRS 

Add UD A and Vehicle Category columns 


YOUNG RNT OVR 

None 


ADDL_DVR_FEES 

Add UDA and Fee Type Columns 








FUELPRCS 

Add UDA hierarchy 



2.3.1 DDL Changes 

The DDL required to support ancillary charges is based on the existing VRS DDL. 

2.3.1.1 MIN_AGE_RSTRS 

3 /The MIN_AGE_RSTRS table identifies a UDA's age restrictions and associated young driver fees. The table supports the 
j*Jise of product type (PRTJPROD JTYP_CD) 9 vehicle class (VCA_CATCD), vehicle class suffix 
£*(CARJXS_SUFX_CDE) 5 and fee type (FEE_TYP_CD) in defining the specific fee and age restriction. Each UDA 
^maintains fees for both contract and non-contract young driver fees. Thus, if a contract provides for a young driver over- 
jjfride, the fee that is charged is the "C" or contract fee (FEE TYPE CD) for the specific UDA. The addition of the 
£|MAX_RNTL_FEE_AMT attribute has provided a flexible, possibly variable, maximum per rental value. The value could 
Wbe varied across product lines, age groups or vehicle classes. The system will utilize the value that is found on the row that 
^contains the young renter fee data. 

w 

si Note: The bty_typ is a vrs column that is being retained. It will not be directly used in the ERAC implementation. 

fijTable Name : MIN_AGE_RS TRS Alias : MAR 

^Display Title : Young driver age info. And fees applied at 

Jjf the uda level for each car class, 

•^Column Summary 


Col. Seq. 

Column 

Null ? 

Type 


1 

STRT DT 

NOT NULL 

DATE 


2 

STA STN ID 


VARCHAR2 

(10) 

3 

UDA AREA ID 

NOT NULL 

VARCHAR2 

(10) 

4 

UDA ATY AREA TYP 

NOT NULL 

VARCHAR2 

(10) 

5 

VCA CAT CD 

NOT NULL 

VARCHAR2 

(8) 

6 

CAR CLS SUFX CDE 

NOT NULL 

VARCHAR2 

(4) 

7 

BTY TYP 

(NULL) 

VARCHAR2 

(2) 

8 

PRT PROD TYP CD 

NOT NULL 

VARCHAR2 

(2) 

9 

FEE TYPE CD 

NOT NULL 

VARCHAR2 

(1) 

10 

REQ AGE 

NOT NULL 

NUMBER 

(3) 

11 

MIN DVG LIC PRD 


NUMBER 

(3) 

12 

CRY ARIMP CRY CD 


VARCHAR2 

(2) 

13 

END DT 


DATE 


14 

MAX AGE 


NUMBER 

(3) 

15 

YNG RNTR FEE 


NUMBER 

(15, 

16 

MAX RNTL FEE AMT 


NUMBER 

(15, 
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Primary Key 

Name Column 

MAR_PK STRTJDT 

MAR_PK UDA_AREA_ID 

MAR_PK VCA_CAT_CD 

MAR_PK CAR_CLS_SUFX_CDE 

MAR_PK FEE_TYPE_CD 

MAR_PK REQ_AGE 

MAR PK PRT PROD TYP CD 


Foreign Keys 
MAR__AP PL I CABLE_I N 

CRY_ARIMP_CRY_CD references CRYS . ARIMP_CRY_CD 

Transferable ? :True ; Mandatory ? :True ; 

Update Rule : Restricted ; Delete Rule : Restricted ; 


JMAR_FOR 

III VCA_CAT_CD references VHCL_CATS . CAT_CD 

pi Transferable ? :True ; Mandatory ? :True ; 

i*i Update Rule : Restricted ; Delete Rule : Restricted ; 

f^MAR_HVC_FK 

]*!, STRT_DT references INV_HIER_VHCL_CAT . EFFJDT 

jlj VCA_CAT_CD references INV__HIER_VHCL_CAT . VCA_CAT_CD_HIER 

5=1 Transferable ? : True ; Mandatory ? :True ; 

|jj Update Rule : Restricted ; Delete Rule : Restricted ; 

Is- 3 

UDA_AREA_ID references USR__DFND_AREAS . AREA__ID 
UDA_AREA_TYP references AREA_TYPES . AREAJTYP 
Transferable ? : True ; Mandatory ? :True ; 
Update Rule : Restricted ; Delete Rule : Restricted ; 


Index Summary 



Name 

Seq. 

Column 

Unique ? 

MAR PK I 

1 

UDA AREA ID 

UNIQUE 

MAR PK I 

3 

VCA CAT CD 

UNIQUE 

MAR PK I 

4 

VCA_CLASS_SFX 

UNIQUE 

MAR PK I 

4 

STRT DT 

UNIQUE 

MAR PK I 

6 

FEE TYPE CD 

UNIQUE 

MAR PK I 

7 

REQ AGE 

UNIQUE 

MAR PK I 

8 

BTY TYP 

UNIQUE 

MAR PK I 

9 

PRT PROD TYP 

CD UNIQUE 
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2.3.1.3 ADDLJDVRFEES 

The ADDLJDVR_FEES table identifies a station's additional driver fees. The actual additional driver fee is based on the 
UDA ID and area type, the fee type (FEE_TYPE_CD), the product type (PRTJPROD JTYPCD), and the number of 
additional drivers (BEGIN QTYJSTBR and END_QTY_NBR), as qualified by valid start and end dates (START DT and 
ENDJDT). 

Table Name : ADDLJDVR_FEE S Alias : ADF 
Display Title : Addl Dvr Fees Variable Additional 
Driver fees applied at the station level. 


Column Summary 
Col. Seq Column 


ffrf 
III 


1 

2 
3 
4 
5 
6 
7 
8 
9 

10 
11 
12 


UDA_AREA_ID 

UDA_ATY_AREA_TYP 

START__DT 

PRT_PROD_TYP_CD 

FEE_TYPE_CD 

BEG1N_QTY_NBR 

FEE_NBR 

FEEJJNIT_CD 

END_DT 

END_QTY_NBR 

MAX_RENTAL_FEE__AMT 

STA STN ID 


Nulls ? 

Type 



NOT 

NULL 

VARCHAR2 

(10) 


NOT 

NULL 

VARCHAR2 

(10) 


NOT 

NULL 

DATE 



NOT 

NULL 

VARCHAR2 

(2) 


NOT 

NULL 

VARCHAR2 

(1) 


NOT 

NULL 

NUMBER 

(12) 


NOT 

NULL 

NUMBER 

(15, 

4) 

NOT 

NULL 

VARCHAR2 

(1) 




DATE 





NUMBER 

(12) 




NUMBER 

(15, 

3) 



VARCHAR2 

(10) 



Hi 


Primary Key 
Name Column 


H|ADF_PK 

f!jADFJ>K 
mADFJPK 
&ADF_PK 

Wadf PK 


UDA_AREA_JED 

STARTJDT 
FEE_TYPE_CD 
PRT_PROD_TYP_CD 
BEGIN QTY NBR 


Foreign Keys 
ADF_UDA_FK 

UDA_AREA__ID references USR_DFND__AREAS . AREA__ID 
UDA_AREA_TYP references AREAJTYPES . AREA_TYP 
Transferable ? : True ; Mandatory ? : True ; 
Update Rule '.Restricted ; Delete Rule : Restricted 


Index Summary 
Name Seq, 


Column 


ADF_PK_I 2 UDA_AREA_ID 

ADF_PK_I 3 START_DT 

ADF_PK_I 4 PRT_PROD_TYP_CD 

ADF_PK_I 5 FEE_TYPE_CD 

ADF PK I 6 BEGIN QTY NBR 


Unique ? 


UNIQUE 

UNIQUE 
UNIQUE 
UNIQUE 

UNIQUE 
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23.1.7 FUEL_PRCS 

The FUEL _PRCS table maintains fuel prices data for UDA's, At each UDA there exists the possibility of maintaining data 
for each of three fuel type codes (FTYJFUEL_TYP_CD) as well as for two fuel price types (FUELJPRC JTYP). The 
revised structure of the FUEL_PRCS table is shown below. 

TABLE NAME: FUEL_PRCS (Station-level pricing) 
TABLE NAME: FUEL_PRCS (UDA-level fuel pricing) 
Column Summary 

Col. Seq. Column Nulls ? Type 


1 UDA_AREA_ID NOT NULL VARCHAR2(10) 

2 UDA_AT Y_ARE A_T Y P NOT NULL VARCHAR2(10) 

3 ST A STN ID VARCHAR2(10) 
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4 FTY_FUEL_TYP_CD NOT NULL VARCHAR2(2) 

5 STRTJDT ' NOT NULL DATE 

6 FUEL_PRC_TYP NOT NULL VARCHAR2{1) 

7 CRY_ARIMP _CRY_CD VARCHAR2 ( 2 ) 

8 END_DT ^ DATE 

9 LIT_COST NUMBER (15, 3 ) (DEFAULT 0) 


Primary Key 

UDA_AREA_ID,UDA__AREA_TYP, STRT_DT, FTY_FUEL_TYP_CD, FUEL_PRC_TYP 

Indexes 

FPR_PK UNIQUE 
UDA_AREA_ID 
UDA_AREA_TYP 

FTY_FUEL_TYP_CD 

STRT_DT 

FUELJPRCJTYP 

Foreign Keys 

FPRJLEVIEDJEN (CRY_ARIMP_CRY_CD) REFERENCES CRYS (ARIMP_CRY_CD) 

,. n Check Constraints 

H[ SYS_C00293 1 ( fod jprcjyp IN ( 'R' , 'F' ) ) 

o 

]^2*3.2 Reference Data 

lit Domain values for various columns in tables used by the ancillary charge service will be stored in the CG_REF_CODES 
Stable. 

M 

^2.3.2.1 Minimum Age Restrictions - MINAGE JISTRS 

^ 2.3.2.1.1 PRT_PRODJEYP_CD 

^ i The product type is used to identify the type of product that characterizes this rental transaction and takes the same domain 
i^t values as "Default Type" which is defined in the glossary. The code is a 2 character code, and will be defined in 
\M PROD TYPS table. 

m 

m Possible Values for Product Type: 




B 

Bodyshop 

C 

Corporate 

D 

Dealership 

G 

Government 

I 

Insurance 

R 

Retail 


2.3.2.1.2 FEE_TYP_CD 

The fee type code is used to identify if a fee is a "S" station or standard young driver fee or a "C" contract fee. The domain 
values are stored in the CGJREF_CODES table with a RV DOMAIN value of MIN_AGE_RSTRS.FEE_TYPE_CD. 


Value 



-.■ 

-hi- 

S 

Standard or Station fee 

c 

Contract fee 
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2.3.2.2 Young Renter Override - YOUNGJRNT_OVR 
2.3.2.2.1 OVERRIDEIND 

The override indicator in the YOUNG_RNT_0 VR table is used to determine if a contract has a young renter fee waive 
provision. If the value of the flag is "Y", then all young renter fees will be waived. If the flag is "N", then the station's "C" 
fee will be charged for the young driver. The domain values for the override indicator are stored in the CGJREF_CODES 
table with a RVJDOMAIN value of YOUNG_RNT_OVR.OVERRIDE_IND. 



Stoning 

Y 

Waive young renter fee 

N 

Do not waive young renter fee. Young renter 
will be charged the "C" fee for the specific 
UDA. 


2.3.2.3 Additional Driver Fees - ADDL_DVR_FEES 
JJ2.3.2.3.1 PRTJPRDJTYPCD 

]*z The product type is used to identify the type of product that characterizes this rental transaction and takes the same domain 
lvalues as "Default Type" which is defined in the glossary. The code is a 2 character code, and will be defined in 
nJPROD TYPS table. 

■ :!. 52. - — 


OPossible Values for Product Type: 





Si 

B 

Bodyshop 


C 

Corporate 


D 

Dealership 


G 

Government 

::; 

I 

Insurance 

.ss."r 

R 

Retail 


2.3.2.3.2 FEE__TYP_CD 

The fee type code is used to identify if a fee is a "S" station or standard additional driver fee or a "C" contract fee. The 
domain values are stored in the CG_REF_CODES table with a RVJDOMAIN value of 
ADDLJ3VR_FEES.FEE_TYPE_CD. 





s 

Standard or Station fee 

c 

Contract fee 






Wm 


mm 




Last Save Date: 11/5/2001 10:31 AM 


Page 13 of 34 


Ancillary Charge Service Detail Design_I3 


Ancillary Charge Service Detail Design 
ECARS v2.0 - Accurate Out the Door Pricing 


perotsystems™ 



Last Save Date: 11/5/2001 10:31 AM 


Page 14 of 34 


Ancillary Charge Service Detail DesignJB 



2.3.2.6 FUELPRCS 

1^2.3.2.6.1 fty_fueljtyp_cd 

J-^The Fuel Type Code specifies the type of fuel that is to be priced The code is a 2 character code used to specify the type of 
JSfiiel that the price refers to. The domain values will be defined in CGJREFCODES under the domain of 

[|fuei^rcs.ftyjfuei^ypj:d. 


.■rvalue 


UL 

Unleaded 

DL 

Diesel 

LD 

Leaded 


ilJ2.3.2.6.2 FUEL_PRCJTYP 

Hi J The Fuel Price Type is used to identify the refueling option, Pre-Paid or Post-Paid, that the price is associated with. The 
l31code is a 1 character code. The domain values will be defined in CG_REF__CODES under the domain of FUELJ>RCS. 
C3FUEL PRC TYP. 


iilriie _ 


F 

Pre-Paid Fuel 

P 

Post-Paid Fuel 
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3,1 Inputs 



Standard Header 


The content of this header 
will be used for debugging, 
user test support, 
performance monitoring, 
tuning and error logging 


refer to standard header 
document for layout and 
population rules 


ndatory 


All Clients 


View Version String 


Identification string for this 
TUX server 


FN__ACHGJ/IEW_VERS10N 


Mandatory 


char 


100 


Tux View 


c 


I co_svc_lvl_code 


Method of Delivery 


FNACHG_CO_SVC J.VL.CDE Mandatory 


char 


Client App 


~=> ci_svcJvl_code 


Method of Delivery 


FNJ\CHG_CI_SVCJVL_CDE 


Mandatory 


char 


Client App 


dvr_age 


Driver's age in years 


FN ACHG DVR AGE 


Mandatory 


ong 


Client App 


cntr id 


Contract id associated with 
this driver 


FN ACHG CON ID 


Optional 


ong 


Client App 


^stn id 


Pick Up station id 


FN ACHG STN ID 


landatory 


char 


11 


Client App 


co_stn_cntry_code 


Pick Up station country 
code 


FN ACHG CNTRY 


landatory 


char 


Client App 


co stn curr code 


Pick Up station currency 
code 


FN ACHG CURR 


Mandatory 


char 


Client App 


I U co_stn_PRD Jyp 


Pick Up station rental type 


FN ACHG STN PRD TYP 


Mandatory 


char 


3 Client App 


w ] stn„area„list 


List of UDAs which a 
station /branch belongs to. 


FN ACHG UDA LIST 


Optional 


char 


4501 


Rate Engine 


Mi 


vehicle category code 


The vehicle category. 


FN ACHG VHCL CLASS 


Mandatory 


char 


Client App 


vehicle class suffix 


The vehicle category suffix 


FN ACHG VHCL CL SFX 


Mandatory 


char 


Client App 


pick_up_date 


Pick up date and time. 
Would be projected 
checkout date and time for 
a reservation. 


: N ACHG PU DATE 


Mandatory 


char 


13 


Client App 


return date 


Return date and time. 
Would be projected 
checkout date and time for 
a reservation. 

Either Return date or 
rental_dur are required. 


FN ACHG RD DATE 


Mandatory 


char 


13 


Client App 


rental dur 


The rental duration in days. 


FN ACHG RNT DUR 


Optional 


ong 


Rate Engine 


Yng_dvr_Geographic_ 
Override 


Indicates that the 
geographic location young 
driver values overrides all 
contractual values. Default 
value = N 


FNJ\CHG YNG.DVR GEOG 
OVR 


Optional 


Char 


Client App 


FueLType 


indicates the type of fuel 
that the service should 
price 


FN ACHG FUEL TYPE 


Optional 


Char 


Client App 


yng_dvr_amt 


Young driver charge 
amount. A value of -1 
causes the service to 


FN_ACHG_YNG_RNTR_AMT Mandatory 


double 


Client App 
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yng_dvr_unitjyp 


nbr_adtl_dvrs 


l«9 


m 

Q 


M adtl_dvr_amt 


0) 

SI 


adtl_dvr_unit_typ 


calculate the amount and 
unit type. Any other value 
will be accepted by the 
service and used in the 
output charge structure 


Young driver charge unit 
type. Required when the 
calling process is 
specifying a yngjntr_amt 
other than -1. (per day or 
per rental) 


The number of additional 
drivers on the rental. A 
value of zero indicates no 
additional drivers. 


FN.ACHG YNG_RNTR_UNIT_ 
TYP 


Optional 


FN_ACHG_NBR_ADTL_DVRS Mandatory 


Additional driver charge 
amount. A value of -1 
causes the service to 
calculate the amount and 
unit type. Any other value 
will be accepted by the 
service and used in the 
output charge structure. 
Required when 
nbr_adtl_dvrs is greater 
than zero. 


Additional driver charge 
unit type. Required when 
the calling process is 
specifying a adtl_dvr_amt 
other than -1. (per day or 
per rental) 


FN_ACHG ADTL DVR UNIT 
[TYP 



FNJ\CHGJ\DTLJDVR_AMT 


char 


Optional 


double 


Optional 



Client App 


ong 


Client App 


8 


Client App 


char 


Client App 


Note: Character field sizes include space for null terminator. 
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3.2 Outputs 

The output of the Ancillary charge engine is structured such that it is similar to the input parameters for the Charge Engine. 
In the cases where a Max Per Rental fee is applicable, the system will output a record that contains the per day charges and 
the Max Per Rental charge. This service will not attempt to optimize the per- day and max per rental charges. It would be 
possible to have a $20 per day charge with a 10 day duration (i.e $200 total) and a max per rental value of $50. These 
base values per day charge, duration, and max per rental will be optimized by the Charge Engine when it is called. The 
reason that these values are not optimized by the Ancillary charge service is because of the likelihood that the branch 
employee may choose to modify the values that are returned by the Ancillary charge engine. 


;;-};/ . . ; Anciiary Charges Service Output Parameters - Version : 01.00 -. - < v ' 









number of Records (0 
-15) 

Number of Ancillary 
records to process 

FN_ACHG_NUM_ANCLJTEMS 

Mandatory 

ong 

4 

Ancillary 

error_no[16] 

Server error Code or 0 

FNACHG_ERR_STATUS 

Mandatory 

long 

4 

Ancillary 

errjext[16] 

Server Error Text 

FN_ACHG_ERR_MESSAGE 

Optional 

char 

81 

Ancillary 

sqLerror_no[16] 

DB Error code as 
applicable 

FN ACHG SQL ERR STATUS 

ODtional 

lona 

4 

Anrtllarv 

vVI 1 \ji lid J 

sqLerrorJext[16] 

DB Error Text as 
applicable 

FN_ACHG_SQLJERRJWSG 

Optional 

char 

81 

Ancillary 

charge jd[1 6] 

Charge id. A sequence 
number that differentiates 
charges in the list 

FNACHGJD 

Mandatory 

ong 

4 

Ancillary 

charge_desc[16] 

Description of the charge. 

FN_ACHG_DESC 

Mandatory 

char 

36 

Ancillary 

charge_amt[16] 

Charge unit amount. 

FN_ACHG _AMT 

Mandatory 

double 

8 

Ancillary 

max_per_rental[16] 

The maximum per rental 
value, if available. 

FN_ACHG_MAX_PER_RNTL 

Optional 

double 

8 

Ancillary 

currency_code[16] 

Currency code ( USD, 
CAD, etc..) 

FN_ACHG_CURR_CDE 

Mandatory 

char 

4 

Client App 

rct_cng_typ[i6] 

onarge type code. 

CM A [j AMrt TV/ OCT 

r N_AC n G_Gn G_T YP t 

Mandatory 

_L_ _ - 

char 

6 

Ancillary 

chg_unit_typ[16] 

Unit type (D=per 
day,R=Per Rental 
Max,C=%-based) 

FN_ACHG_U N IT_TYPE 

Mandatory 

char 

1 

Ancillary 

start_dt[16] 

Start date 

(YYYYMMDD24HHM!) 

FNJ\CHG_ST_DATE 

Mandatory 

char 

13 

Client App 

end_dt[16] 

End date 

(YYYYMMDD24HHMI) 

FN_ACHG_END_DT 

Mandatory 

char 

13 

Client App 

charge_duration[16] 

Duration of the charge in 
the number of charge 
units. 

FN_ACHG_DRTN 

Mandatory 

long 

4 

Ancillary 

NumFuelPrices (0-4) 

The number of fuel price 
records returned. 1-5 
items 

FN_FUEL_PRCJTEMS 

Mandatory 

Long 

i 

Ancillary 

Error_no[5] 

Server error Code or 0 

FNACHG_SVC_ERR_STATUS 

Optional 

long 

4 

Ancillary 

Errjextp] 

Server Error Text 

FN_ACHG_SVC ERRMESSAGE 

Optional 

char 

81 

Ancillary 
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tilsasli 


... Output Parameter 




IllltS 


sql_error_no[5] 

DB Error code as 
applicable 

FN_ACHG_SVC SQLERRSTATUS 

Optional 

long 

A 

MlH/tlieli y 

sql_errorJext[5] 

DB Error Text as 
applicable 

FN_ACHG_SVC SQLERRMSG 

Optional 

char 

81 

AnHllarv 

Fuel Payment 
Type[5] 

The type of fuel payment 
option (Pre Paid, Post 
Paied or Pump price) 

FN_FUEL_PAY_TYPE 

Optional 

Char 

2 

Ancillary 

Fuel Price[5] 

The price per unit of fuel. 

FN_FUEL_PRICE 

Optional 

Double 

8 

Ancillary 


Note: Character field sizes include space for null terminator. 


3 ! 

l"IJ 


yj 


Pi 
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3.3 Detailed Process Flow 

The Ancillary charge service determines specific ancillary charges and then formats the charges into a structure, which will 
be used as input to the charge engine. The service will support a calling process passing in a specific value for a charge 
item. 



Calculate Young 
Driver Fee 


Calculate 
Additional Driver 
Fee 


Calculate After 
Hours Fee 


Get Fuel Prices for 
UDA 


Build Output List 



3 
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3.4 Sub Functions 


3.4.1 Young Driver Fee Process Flow: 

Young driver fees are calculated based on age ranges, car classes, car class suffixes, product types, and fee types established 
and maintained in the UDA hierarchy. There are two types of young driver fees. One set of fees, "S" (standard) fees, are 
applied in cases where the young driver does not have a contract that overrides the UDA young driver conditions. The 
second type of young driver fee is a contract fee, "C". "C" fees are applied whenever a young driver has a contract that 
overrides the UDA's young driver conditions, but does not override the young driver fee. 
The UDA hierarchy search will be designed so that data at the lowest level will take precedence. Thus, if a branch 
establishes young driver fees, they will in effect override the values established at higher levels of the UDA hierarchy. In 
the case where no records are found in the UDA hierarchy, the system will return no restrictions and a fee of zero. 


us 


His* 
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Note: 

If the Geographic Young 
Renter Override flag = "Y" 
then do not consider contract 
parameters. 

If the flag = "N", (default), 
evaluate contract young 
renter conditions. 



The main database entity that drives the young driver fee logic is the Minimum Age Restriction table (MIN_AGE_RSTRS). 
If an UDA desires to set explicit young driver restrictions or fees, the restrictions are stored in the MIN_AGE_RSTRS table. 
Each rental station contains young driver fee data that is derived by vehicle category (VCA__CAT_CDE), rental type 
(PRDJTYP), and the young driver fee type (FEE JTYPE_CD). The young driver fee type is either "S" for the UDA 
standard young driver fee, or a U C S for the UDA's contract override young driver fee. Rental type is used in the case where 
young driver fees or age limits differs for different product types. Some rental types are Retail, Insurance Replacement, or 
Corporate. 
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The following is a representation of sample data from MIN_AGE_RSTRS where a group has established cases where young 
renter fees should not be charged. One of the branches in the group, has opted to override the young driver limit for 
insurance product, and has also established young renter fees for retail rentals of specific car classes. 
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ATY GROUP 

ACAR 

** 

RT 
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25 

99 
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75 

01 

ATY_GROUP 

ACAR 

** 

RT 
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25 

99 

o 

75 

01 

ATY_GROUP 

ACAR 

** 
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23 

99 
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75 

01 

ATY GROUP 

ACAR 

** 

IN 
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23 

99 

0 

75 

01 

ATY GROUP 

ACAR 

** 

CP 

c 

25 

99 

0 

75 

01 

ATY GROUP 

ACAR 

** 

CP 

s 

25 

99 

0 

75 

0101 

ATY BRANCH 

ACAR 

** 

IN 

c 

25 

99 

0 

75 

0101 

ATY BRANCH 

ACAR 

** 

IN 

s 

25 

99 

0 

75 

0101 

ATY BRANCH 

CCAR 

** 

RT 

s 

21 

24 

25 

75 

0101 

ATY_BRANCH 

ECAR 

** 

RT 

s 

21 

24 

25 

75 

0101 

ATY_BRANCH 

FCAR 

** 

RT 

s 

21 

24 

25 

75 

0101 

ATY BRANCH 

ICAR 

** 

RT 

s 

21 

24 

25 

75 

0101 

ATY BRANCH 

SCAR 

** 

RT 

s 

21 

24 

25 

75 

0101 

ATY BRANCH 

PCAR 

** 

RT 

s 

21 

24 

50 

100 


03.4.2 Additional Driver Process Flow: 

111 

0 JAdditional driver fees are calculated based on the number of additional drivers and product type information established and 
□maintained in the UDA hierarchy. 

yjThe UDA hierarchy search will be designed so that data at the lowest level will take precedence. Thus, if a branch 
m establishes additional driver fees, they will in effect override the values established at higher levels of the UDA hierarchy. 
j B iJn the case where no records are found in the UDA hierarchy, the system will return a fee of zero. 

^ jSimilar to young driver, there are two types of additional driver fees- "S" -standard fee and "C" contract override fees. This 
^process is different from young renter fees in that a single contract indicator is used to determine which fee to select. The 
•KADDI^DVRJND indicator in the CONS JND table could contain the following values: "W" - Waive Fee, "C" - Use 
^Contract fee, or "S" - Use standard fee. 
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^Additional Driver 


Num of Add! Dvrs 
BranchID 
Product Type 
Contract 


Get UDA Additional Driver 
data based on UDA ID 
and Productl Type 



8 5 



Additional drivers are calculated based on values set and maintained in the UDA hierarchy. The additional driver fee 
calculation process does not take into account the age of the additional drivers. In order for a young driver fee to be 
determined for an additional driver, the client application will need to specifically call the engine with the additional driver 
age information in order to calculate the additional young driver fees if appropriate. 
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3.4.4 Sub Functions Specifications 

The ancillary charge internal sub functions utilize a common Input and Output structure to manage data internally. 
The input and output structures are defined below (these structures are identical to the fields and views that handle 
input and output for the tuxedo server and are the Pro*C representation of those structures). 


0 
P 


res 

ass 

? -ST 

flJ 




^^^^ 

string 

user id 

16 

string 

session id 

20 

string 

call tree 

150 

string 

function 

16 

long 

process mask 


string 

view version 

100 

string 

co svc lvl code 

3 

string 

ci svc lvl code 

3 

long 

dvr Age 


long 

cntr id 


string 

stn id 

11 

string 

co stn entry code 

3 

string 

co stn curr code ! 

4 

string 

co stn prd typ 

3 

string 

stn area list 

100 

strins 

vhel cat cd 

9 

string 

vhel els sfe 

5 

string 

pick up date 

13 

string 

return date 

13 

long 

rental dur 


char 

yng dvr Geo Override 


string 

fuel Type 


double 

yng dvr amt 


char 

yng dvr unit typ 


long 

nbr adtl dvrs 


double 

adtl dvr amt 


char 

adtl dvr unit typ 


double 

after hrs amt 


char 

after hrs unit typ 
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Ou tput Structure (out anc chg): 


a 
p 

I si 

Iff? 3? 




mum 


long 

error no 

i 


long 

num charges 

i 


long 

chg error no 

1-15 


string 

chg error text 

1-15 

81 

long 

chg sql error no 

1-15 


string 

chg sql error text 

1-15 

81 

long 

charge id 

1-15 


string 

charge desc 

1-15 

36 

double 

charge amt 

1-15 


double 

max_per rental 

1-15 


string 

currency code 

1-15 

4 

string 

ret chg typ 

1-15 

6 

char 

chg unit typ 

1-15 


string 

start dt 

1-15 

13 

string 

end dt 

1-15 

13 

long 

charge dur 

1-15 


long 

fuel error no 

1 


string 

fuel err text 

1 

81 

long 

fuel sql error no 

1 


string 

fuel sql error text 

1 

81 

long 

num fuel prices 

1 


string 

fuel pay type 

1-5 

2 

double 

fuel price 

1-5 

8 


jsystemName: 

Ancillary Charge Service j 

^Module Name: 

ACE Get YD Fee 

= Module Return 
|Type: 

int 

' fModule Language: 

ProC 

Library Name: 


Brief Description: 

Function determines young driver fees for a rental transaction. _J 

Number of 
Parameters: 

3 

Input Parameters 

Description 

|Type 

(Required 

[Default 

inancchg 

Ancillary Charge Input Parameters 

(struct* 

|v 

[input 

out anc chg 

Ancillary Charge Output Parameters 

(struct* 


|Output 

AreaHier 

MKTC7500G_AreaHierarchy (UDA 
hierarchy) 

(struct* 


jlnput 

Input Requirements: 

As seen above 

Output: 

The output of the ACE_Get_YDJFee is the per day fee, max per rental amount, and any applicable 
error codes and messages. 

Detailed Description: 

ACE_Get__YD__Fee determines the appropriate young driver fee for a given driver age, branch, 
vehicle class, vehicle class suffix, product type, and fee type. 


a 


j jjSystem Name: ]|Ancillary Charge Service 
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IVfnrlnle Name' 

ACE Get AD Fee 1 

HIUUUIL A vt- IU1 El 

int j 

Type: 

IVTnrfiilp T ^ancniacrf 

ProC 

Library Name: 


Brief Descrintion: 

Function determines additional driver fees for a rental transaction. 

Number of 

3 



Parameters: 




InDut Parameters 

Description frype 

[Required 

"^Default ~" 1 

in anc che 

Ancillary Charge Input Parameters jjstruct* 

Y 

Jnput 

out anc chg 

Ancillary Charge Output Parameters ^{struct* 

Y 

JfOutput J 

AreaHier 

MKTC7500G_AreaHierarchy (UDA IL^ 
hierarchy) || 

Y 

jjlnput 

Tnnnt Xi. pn ni r^m fonts' 

MijJUl XVGIJU11 willvUla* 

As seen above. 

Output: 

The output of the ACE_Get_ADJFee is the per day fee, max per rental amount, and any applicable 
error codes and messages. 

; Detailed 
: Description: 

ACE_Get_AD_Fee determines the appropriate additional driver fee and fee unit type for a given 
number of additional drivers, branch, product type, and fee type. 



System Name: 

fAncillary Charge Service ! 

jModule Name: 

|ACE Get Fuel Prcs 1 

[Module Return 
fType: 

jint | 
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IVTnHnlp T ,Qfi0H5i<7P* 

IProC S 

-LuUJTarj upline. 

1 

DJT1C1 J^CdvI lpllisll* 

Function determines fuel prices for a rental transaction. Hi 

INFiimhpMr nf 

|i 1 UlllUtl Ul 

Parameters: 

i 

[XilfJUi raiaiiicicia 

Description jType 

[Required 

fDefauit | 

lin jhip c\\o 

liii CUlw vug 

Ancillary Charge Input Parameters ((struct* 


jlnput 

jout_anc_chg 

Ancillary Charge Output Parameters ((struct* ||Y 

foutput 

UreaHier 

MKTC7500G_AreaHierarchy (UDA ({struct* 
hierarchy) |j 

Y 

jlnput 

iTnniif R^niiireTnents: 

gJLH|JUl l\Cl(Uli tlUvUli}* 

(As seen above. 

jOutput: 

jThe output of the ACE_Get_Fuel_Prcs are the fuel prices, fuel price types, and any applicable error 
(codes and messages. 

betailed 
(Description: 

kCE_Get_Fuel_Prcs determines the appropriate fuel prices and fuel price types for a given fiiel type 
|and branch. 


in 


mi 

Ni 
ill 


1(5- 

* a 


3.5 Calling Processes Variations 

3.5.1 Reservations 

The calling process during reservations will be required to estimate checkout date and rental duration. 

3.5.2 Open Ticket 

At Open Ticket, the checkout station and date are known, but the rental duration must be estimated. 

3.5.3 Modify Ticket 

The modify ticket call process may require a series of calls to the engine in order to determine young driver fees. Since 
young driver fees are partly based on vehicle class, it would be possible for the young driver fee to change as the result of a 
vehicle change. Additionally, a change in rental start date (between the time of the reservation and the actual rental) could 
potentially change young driver, additional driver, and after hours fees as well as fuel prices since all of these fees are 
subject to effective start and end dates. 

3.5.4 Close Ticket 

The close ticket process contains all of the information to accurately determine the actual ancillary charges. Data that was 
estimated in the Reservation or Open ticket processes, should be known in close ticket. 
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4.1 Assumptions 


a b S 
Si 

| i 

Ill 
111 

m 

is' 


Initial Description 


Young driver fees are based on station age restrictions, vehicle 
category, product type, and contractual over-ride of station fees 
and or age restrictions 


Notes 


OK 


Rental type used in young driver fees enable a station to have 
different fees for different types of rental transactions. Sample 
domain for rental type used in young driver fees are: 

Bodyshop 

Dealership 

Corporate 

Insurance 

Retail 

Government 


OK 


Contracts do not establish specific young driver fees. They only 
override the station fees. 


OK 


Stations maintain two levels of young driver fees for renters. A 
standard fee for underage renters without a contract, and a second 
fee for underage renters with a contract that has underage renter 
provisions. Furthermore, a contract can waive the underage fee 
altogether. The possible young driver fee situations for a retail 
rental would be: 

A . If a young driver does not have a contract at all, then the 
renter is charged the station standard young driver rate 

B. If a young driver has a contract that does not have a young 
driver provision, then the renter is charged the standard station 
rate. 

C. If a young driver has a contract that does have a young driver 
provision, but does not waive the young driver fee, then the renter 
is charged the station's "contract" rate. 

D. If a young driver has a contract that does have a young driver 
provision, and waives the young driver fee, then the renter is 
charged zero. 

The following table summarizes the impact that contract 
indicators have on young driver fees: 


Status 


Closed 


Closed 


Closed 


Overall -OK. 

-Further Requirement: 

1 . When the system fails to find data 
for a specific station, or condition, 
the default behavior will be to return 
zero fees or restrictions. 

2. Need to anticipate that initially, 
most branches will not set up fee 
information. 

3. The behavior of defaulting to 
zero fees or restrictions is true for 
all ancillary charges. 

4. . The values for young renter fees 
are stored in the UD A hierarchy 
with the lowest level of the 
hierarchy taking precedence 


Closed 



Enterprise 
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3*5! 3 


III 


a 


6 


Situation 



w/o Contract 


w/ Contract but 
does not have 
young driver 
provision 


w/ Contract w/ 
young driver 
provision but 
does not 
override the 
young driver 
fee 


Contract data 


Has;- 
Coifracfc 


N 


w/ Contract w/ 
young driver 
provision, 
waives the 
young driver 
fee _ 


'driver 
prdyision?! 


N 


Young^ 
Waive > 


N 


Fee 


values) 


40 


40 


Young driver fees apply to the renter, not additional drivers. 


Additional driver fees are based on values established by the 
UDA. 


Actual requirement is: 

1. Young driver fees apply to the 
renter and additional drivers as 
needed. 

2. In the case of additional drivers, 
multiple calls to determine the 
young driver fee will be required. 

3. Multiple young driver fees could 
potentially be charged on a single 
rental given multiple young drivers. 


Closed 


Ancillary charge data is maintained at the station level, the data is 
not maintained in the UDA hierarchy. 


Actual Requirement is: 

1 . Additional driver fees are based 
on logic similar to young driver 
fees. 

2. Additional driver fees will be 
determined by; 
-product type and 
- contractual over-ride or waiver of 
fees 

3. The values for additional driver 
fees are stored in the UDA hierarchy 
with the lowest level of the 
hierarchy taking precedence." 


Closed 


After hours fees are allocated based on the rental Check-Out time 



Actual Requirement is: 

1. Ancillary charge data is 
maintained in the UDA hierarchy, 
with the data at the lowest level 
taking precedence.' 


Closed 


Actual Requirement is: 

After hours fees are based on rental 


Closed 
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check out and/or check in time 



9. 

ERAC will develop data maintenance forms for the ancillary 
charge tables 


Closed 


10 

The STTSLSCHEDS table does not contain Branch Opening 
/Closing times, but does contain start and stop times for when an 
After Hours Fee would be applied. There is no relational link 
that ties the Branch Opening/Closing times to the times contained 
in the STN_SCHEDS table. 


Open 

S 

IBS' 
11 J 

| !B J 

11 

The Minimum Age Restrictions table contains age ranges where 
young driver fees are defined by UDA, vehicle class, vehicle 
class suffix, product type, and fee type. The lowest age listed in 
the table for a specific UDA, vehicle class, business type and fee 
type defines a "minimum age to rent". It is possible for a specific 
UDA to have multiple '^minimum age to rent" values that vary by 
vehicle class, vehicle class suffix, product type or fee type. When 
a driver's age is below the minimum age for a given set of 
parameters, the service will return an error message. When the 
engine does not find any young driver data in the UDA hierarchy 
for the vehicle class, product type, and fee type combination, the 
engine will return a young driver fee of zero, and will include an 
error value that indicates no records were found. Furthermore, if 
all data matches except that the age is greater than any age range 
at the lowest UDA for which data exists then an appropriate "Old 
enough to rent without a fee" message and a fee of zero will be 
returned. 

OK 

Closed 

Li 

12 

Charge frequency for additional drivers and young renters will be 
either per day or per rental, depending on the values established 
by the UDA. The maintenance forms will ensure that a given 
r*™rH tlift charge freauencv will be either per day or per rental 

The actual requirement is to have a 
Per-Day charge frequency and 
implement a Maximum per rental 
value. 

Closed 

!U — 

IP A * 

6 

Issues 



# 

Description 

Notes 

Status 


1 

Is there a business requirement to calculate fees associated with 
after hour check out of vehicles? 

Yes, need exists for European 
business. 

i^iOScQ. 


2 

If there is a business requirement to calculate after hour check out 
fees, what are the rules that apply to determine the fee? 

Yes, still need to determine 
requirements. John E. and Jack to 
discuss current YRS functionality. 

Closed 


3 

Is the 2 level young driver fee structure (station standard fee and 
station 'contract' fee) sufficient? 

_ 

No, Need to utilize UDA hierarchy 
with the data at the lowest level of 
the hierarchy taking precedence.. 

Closed 
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4. 


The valid charge frequency for each of the ancillary charges needs 
to be defined. For example, (Per Rental, daily, weekly, monthly). 
The current values are listed in the following table: 


Charge 

Per Rental 

Daily 

Weekly 

Monthly 

Young Driver 

Not Valid 

Valid 

Not 
Valid 

Not Valid 

Additional 
Driver 

Valid 

Valid 

Not 
Valid 

Not Valid 

After Hours 

Valid 

Not 
Valid 

Not 
Valid 

Not Valid 


The actual requirement is to have a 
Per-Day charge frequency and 
implement a Maximum per rental 
value for Young Driver and 
Additional Drivers. 


Closed 


6. 


7. 


How do you handle if young retner fees of zero is returned for a 
non-young renter if there is no specific entry created in minOage- 
rstrs for ages of 25 to 99. There are several options under 
consideration: 

1. Have data maintenance forms always create a row for every 
hierarchy level for ages 25 to 99 and fees of 0. 

2. Hard code theAPI to not return the fees of 0 for ages 25 to 99. 

3. Have the data maintenance insert entries at the highest possible 
level in the hierarchy of ages 25 - 99 with a fee of zero. So long 
as lower levels of the hierarchy do not override these entries, the 
syetem will return a fee of zero. The client will be able to drop the 
fee when calling the charge engine. 

4. If the system does find rows with a fee, return a fee of $0, and 
an error code indicating that the driver's age was above the age 
ranges w here a fee existed. 


The actual requirement is that the 
data found at the lowest level of the 
UDA hierarchy will be assumed to 
be complete (i.e., containing data 
for all fees that need to be charged 
by that UDA). Hence, if no rows 
are found at that level of the UDA 
then an appropriate error message 
will be returned to the client (either 
"Too young to rent" , "No data 
found", or "Old enough to rent 
without a fee") in the output 
structure and the search will not 
continue up the UDA hierarchy to 
find a matching row. 


The requirement to support cases where branches can override any 
contractual young renter provisions(New York). A new input 
parameter will be added to the interface, enabling the calling 
application to specify if this branch desires to override any young 
renter contractual provisions. 


The input parameter 
yng_dvr_Geo JDverride will be used 
as a flag to signal the override of 
any contractual young driver 
provisions. 


Closed 


Closed 


If the calling process specifies a Young Driver Fee, or an 
Additional Driver fee, should the ancillary charge service attempt 
t o apply a "Max Per Rental" optimization? 


Open 


8. 


Need to determine how pre-purchased fuel prices will be 
maintained. 


Open 


9. 


Fuel Prices will be maintained in VRS. There might be a 
requirement to have separate fuel cost for fleet rentals 


Open 
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LI Overview 

The purpose of this document is to provide detailed design specifications for product and rates related data set up 
and associated Main Rate Engine component of VRS pricing engine. The scope of this document is to address all the 
gaps for these components that are part of iteration 2 as defined in 6 Gaps Addressed Section' of this document. In 
VRS the rental product has a set of basic attributes, reservation applicability and set of basic rental charges based on 
the pickup location and/or rate hierarchy. In addition, the VRS products are classified into three different levels of 
hierarchy mainly for reporting purposes. VRS Main rate engine accepts a set of predefined inputs for the rental 
transaction and suggests the most appropriate rental product along with the rental charges for the specific transaction. 
Section 2 describes the detailed design for all the data set up requirements for products and rates. Section 3 
describes the process flow and API specification for main rate engine. 


1.2 Dependencies 

us- 
III 

!*% Dependencies with ERAC's Test windows etc. 


J 1.3 Data Conversion 


High level impacts to Data Conversion. A separate document will be published for data conversion design. 

II 1.4 Impact Analysis 


1.4.1 Products 

The Products area primary impact is the Rate Engine. Any changes and updates to the products directly impact the 
Rate Engine and indirectly impact the other VRS functional areas. 

1.4.2 Rate Engine 

The Rate Engine accepts input from the user interface. These inputs along with the product information stored in 
database tables is used by the Rate Engine to identify and return the suggested rate and product for a given rental 
transaction. Therefore, the main rate engine impacts are the user interfaces and the product tables. 
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2.1 Products / Rates Data Set-up 
2.1.1 Products - Data Set-up 

The following sections will depict the data set-up process for the ERAC products 
2.1.1.1 Use Case: User Creates Product Type 


Product type is at the highest level of the VRS product hierarchy. Product type is used to describe the general line of 
business that the product instances defined beneath it are associated with. There are no pre-defined product types 
3 within the VRS system. Product types are created by the business users based on business requirements. There is no 
11 limit to the number of product types that can be defined. The PROD_TYPS table stores all valid product types 
defined within the VRS system. 

Coverages, rates, and messages can be defined and priced by product type. One option for retrieving rates in the 
VRS system will be to request rates based on product type. A valid product type can be passed to the VRS rates 
engine in the rate source field. All applicable products matching the input product type at the lowest level of the 
Li location hierarchy will be returned to the caller. 


r ™l Tn Context- One product type will need to be created for each line of business having 
i,oai in v.uui«it. s ^ of products md rates when a product type is created, the 

Q appropriate data will be added to the PRODTYPS table. 

\A „ This Use Case deals with Create and Update activities on the VRS 

3COP product types table (PRODTYPS). 

Level: 

Pre-Condition: None 

Success End Condition: Product type created 

Failed End Condition: Product type not created successfully 

Primary Actor: User responsible for maintaining product type data (Super User). 

Trigger Event: New P roduct ^ is createcL 
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2.1.1.1.1 Main Success Scenarios 

There are four steps to creating a product type. 

Step 1: User specifies a new product type code. 

This code can be up to two characters in length. It must not already exist on the product types table. 

Step 2: User provides a description of the new product type. 

The description can be up to 35 characters in length. 

Step 3: User provides billing cycle indicator. 


The billing cycle indicator is a one character value. It specifies whether the associated rates are billed out as a 
calendar day or a twenty four hour day. Valid values are "C (Calendar Day) and "T" (Twenty four hour day). 



Column Description 


Column Name 


Data Type 



#Product Type Code PROD_TYP_CD Varchar2(2) 

Product Type Description PROD_TYP_DESC Varchar2(35) 

Billing Cycle: BILLCYCCDE Varchar2(l) 


*Bolded fields represent mandatory attributes for Product Types entity. 



2. ILL LI Scenario 1 - User Creates New Product Type 


The following data is provided by a user to create a product type: 


Product Type Code: R 

Product Type Description: Standard Retail Rates 

Billing Cycle: <H> Twenty four hour day 


The following record will be added to the product types table (PROD JTYPS): 


Product Type Product Type Description 
Code 


Billing Cycle 


I Standard Insurance Rates 


B Standard Body Shop Rates 


D Standard Dealership Rates 


R Standard Retail Rates 


H 


S Special Rates 


* Bolded row indicates new entry added for this scenario 
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2.1.1.1.2 Scenario Variations 

2.1.1.1.2.1 User Updates Product Type 

The only information that can be updated for an existing product type is the product type description. No 
other updates may be made to the record. In order to update the product type description, the user 
overtypes the existing text 

2.1.1.1.2.2 User Deletes a Product Type 

A user can delete the product type if there are no product families defined for it. 
Create/Update/Delete access will be available to super user only. 

2.1.1.1.3 Related Information 

2.1.1.1.4 References/Appendix -A 
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2.1.1.2 Use Case: User Creates Product Family 

Product family is at the second level of the VRS product hierarchy. Product family is used to create sub categories 
of product types. There are no pre-defined product families within the VRS system. Product families are created by 
the business users based on business requirements. There is no limit to the number of product families that can be 
defined. 

Every product family is associated to one and only one product type. A product type will have zero or more product 
families associated with it.. 


Goal In Context: 


feta? 

iff 


w 

s; 

:s S 

Im 


Scope: 
Level: 

Pre-Condition: 
Success End Condition: 
Failed End Condition: 
Primary Actor: 
Trigger Event: 


In order to offer rates for a product of a given product type, a minimum 
of one product family will be created for each product type. Additional 
product families can be created as business needs dictate. When a 
product family is created, the appropriate data will be added to the VRS 
PRODS table. 

This Use Case deals with Create and Update activities on the VRS 
product families table. (PRODS). 

Product types table populated. 

Product family created. 

Product family not created successfully 

User responsible for maintaining product family data (Super User). 
New product family is created. 


2.1.1.2.1 Main Success Scenarios 

There are four steps to creating a product family. 

Step 1: User specifies the product type that the new product family will be associated with. 

The product type specified must already exist in the product types (PRODJTYPS) table. 

Step 2: User specifies a new product family code. 

This code can be up to four characters in length. It must not already exist on the product families table. It 
the product family code entered already exists, an error message is displayed and no data creation occurs. 

Step 3: User provides a description of the new product family. 

The description can be up to 35 characters in length. 

Step 4: User saves record. 

The row is created in the product families (PRODS) table. The primary key for this record is the product 
family code (PROD_ID). 
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Column Description Column Name Data Type 

#Product Family Code PROD JD Varchar2(4) 
Product Family Description PRODJDESC Varchar2(35) 
Product Type Code PRT J>RODJTYP_CD Varchar2(2) 

*Bolded fields represent mandatory attributes for Product Families entity. 

2.1.1.2.1.1 Scenario 1 : User creates new Retail product family 

The following data is provided by a user to create a product family: 

Product Family Code: RUNL 

Product Family Description: Standard Retail Unlimited Mileage 
Product Type Code: R 


The following record will be added to the product families table (PRODS): 


u 

m 


Ml. a 

"5: 

I B S 


01 


Product Family 
Code 

Product Family Description 

Product Type 
Code 

RLMM 

Retail Limited Medium Free Miles 

R 

RUNL 

Standard Retail Unlimited Mileage 

R 


Primary key of 4 characters [A-Z] No special characters are allowed. 
Product type must exist in PRODJYPS table. 
Bolded row depicts data added for this scenario 

2.1.1.2.1.2 Scenario 2: User creates new Special product family 

The following data is provided by a user to create a product family: 


Product Family Code: 
Product Family Description: 
Product Type Code: 


WSRT 

Weekend Special 
S 


The following record will be added to the product families table (PRODS): 


Product Family 
Code 

Product Family Description 

Product Type 
Code 

RLMM 

Retail Limited Medium Free Miles 

R 

RUNL 

Standard Retail Unlimited Mileage 

R 

WSRT 

Weekend Special 

S 


* Bolded row depicts data added for this scenario 
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2.1.1.2.1.3 Scenario 3: User creates new Retail product family for Bid Pricing 
The following data is provided by a user to create a product family: 


Product Family Code: 
Product Family Description: 
Product Type Code: 


BIDR 

Bid Price Retail Rates 
R 


The following record will be added to the product families table (PRODS): 


Product Family 
Code 

Product Family Description 

Product Type 
Code 

RLMM 

Retail Limited Medium Free Miles 

R 

RUNL 

Standard Retail Unlimited Mileage 

R 

WSRT 

Weekend Special 

S 

BIDR 

Bid Price Retail Rates 

R 


* Bolded row depicts data added for this scenario 

2.1.1.2.2 Scenario Extensions 

2.1.1.2.3 Scenario Variations 

2.1.1.2.3.1 User Updates Product Family 

The only information that can be updated for an existing product family is the product family 
description. No other updates may be made to the record. In order to update the product family 
description, the user overtypes the existing text 

2.1.1.2.3.2 User Deletes a Product Family 

A user can delete a product family as long as there are no product instances created for this family, 
Create/Update/Delete access on this entity is restricted to Super Users only. 

2.1.1.2.4 Related Information 

2.1.1.2.5 References 
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2.1.1.3 Use Case: User Creates Product Instance 


Product instance is at the third level of the VRS product hierarchy. The VRS product instance is used to identify a 
product offering and will be used by the VRS rates header to offer rates at a specific location in the Enterprise 
location hierarchy. There are no pre-defined product instances within the VRS system. Product instances are created 
by the business users based on business requirements. 

Every product instance is associated to one and only one product family. A product family will have zero or more 
product instances associated with it. There is no practical limit on the number of product instances that can be 
associated to a given product family. 

Product instance allows the user to define certain basic attributes for the product like product name, description, 
country of ownership, etc. Various set of rates are defined for the product instance based on the Pick Location (In 
VRS this is represented by an entity called RATESJHEADER). The common attributes for the product like 
reservation applicability are defined for a specific product instance instead of repeating it for each of the 
RATESJHEADER record for that product. 

Goal In Context: When a product instance is created, the appropriate data will be added to 

the PROD JNSTS table. 
Scope: This Use Case deals with Create and Update activities on the VRS 

|J3 * product instance table. (PRODJNSTS). 

Q Level: 

Pre-Condition: Product types and product family tables populated. 


y.z: 


JS-::. 
I ii ?. 


W 


II 3 


Success End Condition: Product instance created. 

Failed End Condition: Product instance not created successfully 

Primary Actor: User responsible for maintaining product instance data (Super User). 

Trigger Event: New product instance is created. 


m* 2.1.1.3.1 Main Success Scenarios 

■w *■ 


There are five steps to creating a product instance. 

Step 1: User specifies the product family that the new product instance will be associated with. 
The product family specified must already exist in the product families table (PRODS). 


Step 2: User specifies a new product instance code. 

This code can be up to eight characters in length. It must not already exist on the product instance table. 

Step 3: User provides a description of the new product instance. 

The description can be up to 35 characters in length. 

Step 4: User provides owning country of the new product instance. 

Must be a valid country code. 

Step 5: User saves record. 

Data maintenance process populates creation user id and creation date/time. The row is created in the 
product instance (PRODJNSTS) table. The primary key for this record is the product instance code 
(PRODJNST_CD). 


Last Save Date: 1 1/5/2001 10:18 AM 


Page 13 of 114 


Consolidated Products and Rates Design J3 


rent-a-car 


ECARS v2.0 - Accurate Out the Door Pricing 
Detailed Design Specification 


perotsystems™ 


Column Description 


Column Name 


Data Type 


#Product Instance Code 
Product Instance Description 
Product Family Code 
Country Code 
Creation Operator ID 
Creation Date 


PROD_INSTS_CD 

PRODJNSTSJDESC 

PRDJPRODJD 

CRY_ARIMP_CRY_CD 

CREATE_USER_ID 

CREATE DT 


Varchar2(8) 

Varchar2(35) 

Varchar2(4) 

Varchar2(2) 

Varchar2(30) 

Date 


=k;ss 


S3 s 

jj 

S -I 


55 

hi 
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*Bolded fields represent mandatory attributes for Product Instance entity. 
2.1.1.3.1.1 Scenario 1 : User creates new Retail product instance 

The following data is provided by a user to create a product instance: 


Product Instance Code: 
Product Family Code: 
Product Instance Description: 
Country: 


LIMMED 
RLMM 

Local Market Medium Free Daily Miles 
US 


The following record represents a row in the product instance table (PRODJNSTS). The tax, surcharge, 
and fuel inclusive flags have been defaulted to N as there has been no requirement identified for bundling of 
these items in iteration 3: 


Product 
Code 

Product Instance Description 

Product 
Family Code 

Country 

Create 
Date 

UNLEMITD 

Local Market Unlimited Mileage 

RUNL 

US 

20-MAY-2001 11:12:13 

LIMMED 

Local Market Medium Free Daily 
Miles 

RLMM 

US 

20-MAY-2001 13:14:16 


Create 
Operator 

Tax 

Included 

Surcharge 
Included 

Fuel 
Included 

NCC1701 

N 

N 

N 

KAA8207 

N 

N 

N 


* Bolded row indicates new data added for this entry 
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2.1.1.3.1.2 Scenario 2: User creates new Special product instance 

The following data is provided by a user to create a product instance: 


Product Instance Code: 
Product Family Code: 
Product Family Description: 
Country: 


WSLMRT 
WSRT 

Weekend Special Local Market 
US 


The following record represents a row in the product instance table (PROD_INSTS). The tax, surcharge, 
and fuel inclusive flags have been defaulted to N as there has been no requirement identified for bundling of 
these items in iteration 3: 


Product 
Code 

Product Instance Description 

Product 
Family Code 

Country 

Create 
Date 

UNLIMITD 

Local Market Unlimited Mileage 

RUNL 

US 

20-MAY-2001 11:12:13 

LIMMED 

Local Market Medium Free Daily Miles 

RLMM 

US 

20-MAY-2001 13:14:16 

WSLMRT 

Weekend Special Local Market 

WSRT 

US 

20-MAY-2001 18:21:43 


Create 
Operator 

Tax 

Included 

Surcharge 
Included 

Fuel 
Included 

NCC1701 

N 

N 

N 

KAA8207 

N 

N 

N 

HAL2001 

N 

N 

N 


* Bolded row indicates new data added for this entry 

2.1.1.3.1.3 Scenario 3: User creates new Retail product instance for Bid Pricing 
The following data is provided by a user to create a product instance: 


Product Instance Code: 
Product Family Code: 
Product Family Description: 
Country: 


BIDRTL 
BIDR 

Bid Price Retail Product 
US 


The following record represents a row in the product instance table (PROD_INSTS). The tax, surcharge, 
and fuel inclusive flags have been defaulted to N as there has been no requirement identified for bundling of 
these items in iteration 3: 


Product 

Product Instance Description 

Product 

Country 

Create 

Code 


Family Code 


Date 

UNLIMITD 

Local Market Unlimited Mileage 

RUNL 

US 

20-MAY-2001 11:12:13 

LIMMED 

Local Market Medium Free Daily Miles 

RLMM 

US 

2O-MAY-2001 13:14:16 

WSLMRT 

Weekend Special Local Market 

WSRT 

us 

20-MAY-2001 18:21:43 

BIDRTL 

Bid Price Retail Product 

BIDR 

US 

20-MAY-2001 18:46:21 


Create 
Operator 

Tax 

Included 

Surcharge 
Included 

Fuel 
Included 

NCC1701 

N 

N 

N 

KAA8207 

N 

N 

N 

HAL2001 

N 

N 

N 

NCC1701 

N 

N 

N 


* Bolded row indicates new data added for this entry 
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2.1.13.2 


Scenario Extensions 


2.1.13.3 


Scenario Variations 


2.1.1.3.3.1 


User Updates Product Instance 


The only information that can be updated for an existing product instance is the product instance 
description. No other updates may be made to the record. In order to update the product instance 
description, the user overtypes the existing text 


Create/Update access on this entity is restricted to Super Users only. 
2.1.1,3.3.2 User Deletes a Product Instance 

A user does not have the ability to physically delete an existing product instance. 

2.1.13.4 Related Information 

2.1.13.5 References/Appendix -A 
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2.1.1.4 Use Case: User Creates Rate Qualification Record 

VRS rate qualifications describe what conditions need to be met in order to qualify for a product at a particular 
location. These conditions include: 

• The "base" duration of the rental (daily, weekend). 

• Minimum length of rental 

• Maximum length of rental. 

• Earliest checkout day and time, 

• Latest checkout day of week and time. 

• Latest check in day of week and time. 

• Days of week the rental period must include. 

• Days of week the rental period must not include. 

• Required overnight keep, by day of week. 

• Minimum charge days, by day of week. 

• Advanced booking rules. 

• Pre-payment rules. 

Base duration of the rental, minimum length of rental, maximum length of rental, and qual description are the only 
components of the rate qualification that must be specified. All other fields are optional. Every product that is 
available for sale in VRS must have a rate qualification attached. Rate qualifications are set up once, and then 
potentially used many times and by many different products. Rate qualification rules will be enforced by the system 
at reservation time. Rate qualification rules may be overridden by the counter agent at open ticket time. 

Standard SI retail products will require one rate qualification record. The weekend special product will require it's 
own rate qualification record. How a rate qualification record is associated to a product and location will be 
discussed in a future use case. 


Create the rate qualification record for a standard SI retail product 
Create a rate qualification record for a weekend special product. When 
the task is complete, the appropriate data will be added to the 
RNT_DRTNBNDS table. 

This Use Case deals with Create activity on the VRS rate qualifications 
table (RNTDRTNJBNDS). 

None 

Rate qualification record created. 
Rate qualification record not created successfully 
User responsible for maintaining rate qualification data. 
New rate qual is created. 


There can be up to ten steps to creating a VRS rate qual for use with standard retail or weekend products. 
Step 1: User specifies rate base unit code 

User specifies the appropriate rate base unit code for the qual. This rate base unit code must be compatible 
with the product it will be associated with. SI retail and special products will use "D" (Daily). 


Goal In Context: 

Scope: 
Level: 

Pre-Condition: 
Success End Condition: 
Failed End Condition: 
Primary Actor: 
Trigger Event: 

2.1.1.4.1 Main Success Scenarios 
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Step 2: User specifies qual description 

User enters a description of the quaL This description can be up to 35 characters in length. 

Step 3: User specifies minimum rental length and minimum rental length unit code 

User specifies minimum rental length and the unit that the minimum rental length is expressed in 
(i.e.<D>ays). Minimum rental length unit code of "D" (Days) will be used for SI retail Minimum rental 
length of zero will be used for most SI retail 

Step 4: User specifies maximum rental length and maximum rental length unit code 

User specifies maximum rental length and the unit that the maximum rental length is expressed in 
(i.e.<D>ays). Maximum rental length unit code of "D" (Days) will be used for SI retail Maximum rental 
length of 30 will be used for most SI retail. 

Step 5: User specifies earliest pick up day of week and time 

User selects first day of week that vehicle may be picked up (i.e. Thurs) from pick list. User specifies 
earliest time (in hh:mi format) that vehicle may be picked up on the day of week specified in first pickup 
day field (i.e. 12:00 for noon pickup). Day of week will be stored as an integer value (1-7) following 
Oracle date standards. Day of week will be represented on the screen to the user in a meaningful way. This 
field is generally used only on quals to be associated with weekend special type products. 

Step 6: User specifies latest pick up day of week and time 

User selects last day of week that vehicle may be picked up (i.e. Sun) from pick list User specifies latest 
time (in hh:mi format) that vehicle may be picked up on the day of week specified in latest pickup day field 
(i.e. 12:00 for noon pickup). Day of week will be stored as an integer value (1-7) following Oracle date 
standards. Day of week will be represented on the screen to the user in a meaningful way. This field is 
generally used only on quals to be associated with weekend special type products. 

Step 7: User specifies latest return day of week 

User selects last day of week that vehicle may be returned and still qualify for special rate. (i.e. Mon) from 
pick list The return time is implicitly defaulted to the time that the vehicle was initially picked up. Day of 
week will be stored as an integer value (1 - 7) following Oracle date standards. Day of week will be 
represented on the screen to the user in a meaningful way. This field is generally used only on quals to be 
associated with weekend special type products. 

Step 8: User saves record. 

Step 9: System retrieves rate qual sequence number 

Data name on data record for sequence number is drtn_bnd_cd 

Step 10: System saves new qual record 

The input record is written to the RNTDRTNBNDS table. The primary key for this record is the 
sequence number drtaj>nd_cd. 


Column Description 

Column Name 

Data Type 

Remarks 

Rate Qual Sequence Number 

Drtn bnd cd 

Number(6) 

Generated Sequence number 

Rate Base Unit Code 

Chg_unit_cd 

Varchar2(l) 

Current valid values: <p^aily 
Possible Future values: ^^^^^^ 

Rate Qual Description 

Drtn bnd desc 

Varchar2(35) 


Minimum Rental Length 

Min rnt drtn 

Number(4) 


Minimum Rental Length 
Duration Code 

Min_rntn_drtn_cd 

Varchar2(l) 

Current valid values : <D>Day s 

<H> Hours 

Maximum Rental Length 

Max rnt drtn 

| Number(4) 
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Maximum Rental Length 
Duration Code 

Max_rntn__drtn_cd 

Varchar2(l) 

Current valid values: <D>Days 

<H> Hours 

Rental Start Day 

Co strt day 

Number(l) 


Rental Start Time 

Co from 

Number(5) 


Rental Latest Day 

Co end day 

Number(l) 


Rental Latest Time 

Co upto 

Number(5) 


Return Latest Day of Week 

Ci day of wk 

Number(l) 



ISff 

Hi 

W 
us 

H 

» s 


m 
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2.1.1.4.1.1 Scenario 1 : User creates new rate qualification record for SI retail 
The following data is provided by a user to create the SI retail rate qual: 


Rate Base Unit Code: 
Rate Qual Description: 
Minimum Rental Length: 
Maximum Rental Length: 


D 

Daily Rental, Maximum 30 Days 
Zero days 
Thirty Days 


The following record represents a row in the rate qual table (RNTJDRTN_BND_CD): 


Rate Qual Seq 

Rate Base 

Qual Description 

Min Rental 

Min Rental 

Max Rental 

Max Rental 

Number 

Unit Code 


Length 

Length Unit 

Length 

Length Unit 

000001 

D 

Daily Rental, 

0 

D 

30 

D 



Maximum 30 Days 






FT! 


in 
m 

ri 

15SL- 


2.1.1.4.1.2 Scenario 2: User creates new rate qualification record for Weekend Specials 
The following data is provided by a user to create the SI weekend special rate qual: 


Rate Base Unit Code: 
Rate Qual Description: 
Minimum Rental Length: 
Maximum Rental Length: 
Rental Earliest: 
Rental Latest: 
Return Latest: 


D 

Weekend Special Noon Thurs Pickup 

Zero days 

Thirty Days 

Noon on Thursday 

Noon on Sunday 

Monday 


Rate Qual 
Sequence Number 

Rate Base 
Unit Code 

Qual Description 

Minimum 

Rental 

Length 

Minimum 
Rental 
Length Unit 

Maximum 

Rental 

Length 

Maximum 
Rental Length 
Unit 

000001 

D 

Daily Rental, No 
Restrictions 

0 

D 

30 

D 

000002 

D 

Weekend Special Noon 
Thurs Pickup 

0 

D 

30 

D 


Rental 

Earliest 

Day 

Rental 

Earliest 

Time 

Rental 
Latest 
Day 

Rental 
Latest 
Time 

Return 

Latest 

Day 






Thurs 

12:00 

Sun 

12:00 

Mon 


* Bolded row indicates new table entry for this scenario 
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2.1.1.4.2 Scenario Extensions 

2.1.1.4.3 Scenario Variations 

2.1.1.4.3.1 User Updates the Rate Oual Record 

No information on the rate qual record can be updated. A different rate qual can be associated with a 
rate header if business conditions warrant. 

2.1.1.4.3.2 User Deletes a Rate Oual 

A user does not have the ability to physically delete an existing rate qual record. 

2.1.1.4.4 Related Information 
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2*1.1.4.5 References - NatRes Pick Up Return Rules and the VRS Rate Qual 

The examples below reconcile the pick up and return rules available within the Enterprise NatRes system and the 
corresponding equivalent VRS function. There are a few differences between the between the NatRes pick up and 
return rules and the VRS equivalent. These differences are highlighted below. 

1. NatRes pick up and return rules are attached at the car class level. The VRS rate qual applies to all car classes 
set up for a given product and location (rate header). Enterprise has agreed that rate quals do not need to be 
attached at the car class level. 

2. NatRes pick up and return rules are explicitly attached at the charge unit level (daily, weekly, monthly, 
weekend). VRS handles the length of a rental week implicitly by extending the lower of the weekly rate or sum 
of daily charges for every period of the rental up to 7 days. The length of a rental month in VRS is expressed at 
the car class level and is specified in the same place the monthly rate is defined. Similar to weekly rate 
processing, the VRS rates optimizer begins extending the monthly rate when the sum of daily and/or weekly 
charges is greater than the monthly rate. 

3. NatRes can extend weekend rates for it's standard retail (Non UM) rate category. VRS uses a separate weekend 
product and rate qual. 



in 
in 
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Rental 

Length 

o 

CO 

Min 
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Rule Type 

Rule Code 

Record Sequence 

Pick Up Day 

Min Days 

Max Days 

Max Rental Days 

PKRT 

P01007 

1 

SUN 

28 

30 


PKRT 

P01007 

2 

MON 

28 

30 


PKRT 

P01007 

3 

TUE 

28 

30 


PKRT 

P01007 

4 

WED 

28 

30 


PKRT 

P01007 

5 

THU 

28 

30 


PKRT 

P01007 

6 

FRI 

28 

30 


PKRT 

P01007 

7 

SAT 

28 

30 



The pickup/return rules shown above were replicated from production ERAC data. The seven pickup/return rules 
and the Month Factor field on the RateDetails row accomplish essentially the same thing. 


The length of a rental month in VRS is determined by the Month Factor setting on the Rate_Details table. The VRS 
rates optimizer will utilize the monthly rate when the sum of some combination of daily and weekly charges exceeds 
_ the monthly rate. The daily rate will be utilized again once the number of days in the rental period exceeds the value 
C in Month Factor. 

0 

I 2.1.2 Rates - Data Set-up 

(39 • 

p 2.1.2.1 Use Case: User Creates Rates Header 

y J The VRS rate header is used to make a given product instance available for rental at a specific location in the 

si Enterprise rate hierarchy. Many rate headers can be defined for a product instance, depending on the number of 

y% locations that a given product is to be offered. 

in 

m Several types of information are stored on the rate header. The rate header contains the product name, the location 
m the product is being offered, and a location specific description of the product offering. Effective start and end dates 
jvjj define when the product is available for reservation. A discount flag allows the user to specify whether discounts can 

be applied to the rates for this rate header. The rate base unit indicator is used to specify the types of rates that will 

be associated with the rate header. 

The remaining field open for user input is the primary rate indicator. If two or more retail products extend rates at the 
same location, one of the products must be flagged as primary. The product flagged as primary will be the first 
returned by the VRS rates engine when two or more products are applicable in a given rental situation. Only one 
product of a given product type can be flagged as primary at a single location (i.e. if two retail products are available 
at a given location, only one can be flagged as primary). There must be one and only one rate flagged as primary for 
a given product type and location. 



2.1.1.4.5.5 ERAC/VRS Comparison 5 - Monthly Rate 


A number of fields stored on the rate header are denormalized from the associated product instance or product type 
tables. These data elements will be identified later in this document. 


Actual rate amounts, mileage limits, mileage charges, and qualification pickup rules are stored in separate tables that 
are related to the rate header. Date and vehicle category specific rate and mileage charges are stored in the VRS rate 
detail table (RATE_DETAILS). Qualifications and pick up rules are housed in the rate qualifications table 
(RNT_DRTN_BNDS). These will each be discussed in detail in separate use cases. 

The rate header is created once when a product is first made available at a hierarchy location. Under most 
circumstances, once the rate header is created, it requires no further maintenance. 
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ERAC user creates a rate header. Rate header and underlying rate detail 
usage and rate header qual association records populated with 
appropriate data and new data records stored in VRS database. 
This Use Case deals with the Create and Update activities on the VRS 
rates header table. (RATES JtfEADER). 

Product types, product family, product instance, and product availability 
tables populated. Appropriate user defined areas created. 

Rates header created. Rate detail usage and rate header qual association 
created behind the scenes. 

Rates header not created successfully. Rate detail usage and rate header 

qual association consequently not created. 

User responsible for maintaining rates header data. 

New rates header is created. 


w Scenario 1 : User creates new rates header 


HJ There following steps detail the process of creating a rates header. 

!M 

M Step 1: User selects the appropriate product 

h? 4 The product code may be entered directly or selected from a pick list. This pick list may be optionally 

y j scoped by product type (i.e. <R>etail) and product family (i.e. <RLMM> Retail Limited Medium Free 

3i Miles) and include the description of the product. The data maintenance process will verify that a valid 

!»! product is entered upon leaving this field. 


m Step 2: User specifies the location that the product is to be offered 

ml The location can be entered directly or selected from a pick list. Location will be in the form of a user 

%i defined area name and UDA type (i.e. UDA name might be 01 and UDA type might be ATYJ3ROUP). 

I"f This combination of UDA name and type will equate to a specific location in the Enterprise rate hierarchy. 

Step 3: User specifies the dates that the product will be available for reservation at the location 

User inputs effective start and end dates for the rate header (i.e. current date - ongoing). These dates 
represent the first and last dates that reservations will be accepted for the product/location. The data 
maintenance process will verify that input start date is not in the past and that input effective end date is 
greater than input effective start date. Date will include the time in hours (24 hour format), minutes, and 
seconds. The time portion of the effective start and end dates are set as follows; 

Effective Start Time: If the input effective start date is equal to the current date, the time portion 
is set to current time. If the effective start date is in the future, the time portion is set to 00:00:00. 
Effective End Time: Set to 23:59:59 

Step 4: User provides a location specific description of the product offering 

The description can be up to 60 characters in length. 

Step 5: User enters rate base unit code 

The rate base unit codes "D" (Daily) or "B" (Bid Price) will be used by Enterprise. The <D>aily rate base 
unit code supports the hourly, daily, weekly, and monthly rates used by the existing SI application as well as 
NatRes Exception rates. The <B>id Price rate base unit will be used for NatRes Bid Price (Active) rates. 


Goal In Context: 

Scope: 
Level: 

Pre-Condition: 

Success End Condition: 

Failed End Condition: 

Primary Actor: 
Trigger Event: 

11.2.1.1 Main Success Scenarios 
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The Other rate base unit codes include "V" (variable), and "P" (Package) and will be introduced as 
required by the other lines of business. 

Step 6: User enters discount applicability flag for this product and location 

Valid values are "Y" and "N'\ A "Y" in this field indicates that discounts may be applied to the underlying 
rate detail An "N" in this field indicates that no discounts may be applied to the associated rates. 

Step 7: User enters primary rate indicator 

If this product is to be considered the "primary rate" of this product type at the specified location, a "P" is 
entered in the primary rate field. An "S" is entered if the product is secondary. The first rate header of a 
given product type created at a specific location should be flagged as <P>rimary. 

Step 8: User selects appropriate rate qual for this product offering <Optionat> 

User selects rate qual from pick list. The value to be stored is an integer. The pick list should display the 
textual description of the quals. The data maintenance process will verify that a valid qual is entered or 
selected. 


jjSia. 


Pi 


pi 

m 


Step 9: User attempts to save the new record. 

Step 10: The data maintenance process validates combination of user defined area name and user 
defined area type 


J ] j Return error if invalid 

01 


Step 11: The data maintenance process checks for existing rate header for the product, location, and 
SJ effective dates 

j p j The data maintenance process verifies that there are no existing entries in the rate header table 

(RATES_HEADER) for the specified product, user defined area, and user defined area type where the 
I L effective start and end dates of an existing row overlap the start and end dates of the row being created. If 

an existing rate header is found, an error message is returned and no record is created. 


Step 12: The data maintenance process verifies primary rate indicator 

If rate header being created has primary rate indicator set to "P", the data maintenance process checks for 
W other active products of the same type at the same location also flagged as primary. If an existing rate 

b h header for a product of the same type at the same location is flagged as primary, an error message is 

generated and no record is created. 

Step 13: The data maintenance process gathers data from related product tables 

The data maintenance process retrieves currency code, tax and surcharge flags, fuel bundling flag, product 
type, and product family from related product tables and populates new rate header with these values. 

Step 14: New rate header sequence number generated 

The data maintenance process retrieves a sequence number from rate header sequence number generator 
and inserts this value into the RTHJJNIQJOD field on the rate header record. 

Step 15: The data maintenance process inserts new row into rate header table 

CREATEJDPERJD field is populated with the ID of the user who created the new record. CREATE_DT 
field is set to current date and time. 
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Step 16: The data maintenance process formats associated rate detail usages row 
(RATE_DETAIL_USAGES) as follows: 


Rate Detail Usage Column 

Source 

RH RTH UNIQ ID 

RTH UMQ ID from new rate header 

RH RTH UNIQ ID REF 

RTH UNIQ ID from new rate header 

RES START DT 

EFFC START DT from new rate header 

RES END DT 

EFFC END DT from new rate header 

CO START DT 

EFFC START DT from new rate header 

CO END DT 

EFFC END DT from new rate header 

CREATE OPER 

CREATE OPER ID from new rate header 

CREATE DT 

Current system date/time 


RES and CO start and end dates will contain both the date and time w/dme in hours, minutes, and seconds. 

Step 17: The data maintenance process inserts rate detail usages row into rate detail usages table 
(RATE_DETAILJJSAGES). 


Step 18: The data maintenance process formats rate header qual association row <If Entered> 
(RATEJEffiADER_QUAL_ASSN) 

Retrieve RATE_HEADER_QUAL_ASSN sequence number from rate header qual association sequence 
number generator 

Format the new row as follows: 


Rate Header Qual Assn Column 

Source 

RHQA UNIQ ID 

Generated sequence number 

RH RTH UNIQ ID 

RTH UNIQ ID from new rate header 

RDB DRTN BND CD 

Value selected from rate qual pick list 

RES START DT 

EFFC START DT from new rate header 

RES END DT 

EFFC END DT from new rate header 

EFFC START DT 

EFFC START DT from new rate header 

EFFC END DT 

EFFC END DT from new rate header 

CREATE OPER 

CREATE OPER ID from new rate header 

CREATE DT 

Current system date/time ; 


RES and EFFC start and end dates will contain both the date and time wMme in hours, minutes, and seconds. 

Step 19: The data maintenance process inserts rate header qual association row into rate header qual 
association table (RATEJHEADER_QUAL_ASSN). 

Step 20: Upon successful insertion of the rate header (RATES JHEADER), the rate detail usages 
(RATE JDETAIL_USAGES), and the rate header qual association table 
(RATE_HEADER_QUAL_ASSN) rows, the data maintenance process issues commit 
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The row is created in the rate header (RATES JHKADER) table. The primary key for this record is a 
system generate sequence number - the rate header unique ID (RTH_UNIQ_JD). Rate detail usages row is 
also created. This table is used internally by the VRS rates engine to determine which set of rate detail to 
retrieve for the rate header. The rate header qual association entry associates reservation and pick up rules 
with this rate header. 


VRS Rates Header 


Column Description 


Column Name 


Data Type Remarks 


S*T1 

5*3 

sfeft 


1.4 


m 

ill 
III 

H 


#Rate Header Identifier 
User Defined Area 
User Defined Area Type 
Rate Header Description 
Product Instance Code 
* Product Family Code 


* Product Type Code: 


Effective Start Date 


Effective End Date 


Rate Base Unit 

Primary Rate Indicator 
Discount Flag 


* Sales Tax Included Flag 

* Surcharge Include Flag 

* Fuel Included Flag 

* Bill Cycle Indicator 
Record Create Date and Time 
Record Creation Operator 


RTHUNIQJD Number(15) 
UDA_AREAJD Varchar2(8) 
UDA_ATY_AREA_TYPE Varchar2(10) 

Varchar2(35) 
PRCJ>ROD_INST_CD Varchar2(8) 
PRD_PRODJD Varchar2(4) 


PRTJPRODJYPJOD Varchar2(2) 


EFFC START DT Date 


EFFC END DT Date 


System generated 


RT_BASE_UNIT_CD Varchar2(l) 


DSCNT FLG 


Varchar2(l) 
Varchar2(l) 


SALESJTX INCL FLG Varchar2(l) 


SCHG INCL FLG 


BILL_CYCCDE 
CREATE_DT 
CREATE OPER ID 


Varchar2(l) 

Varchar2(l) 

Varchar2(l) 
Date 

Varchar2(32) 


Denormalized from product 

instance 

record. 

Retrieved from product family 
table 

Time in hh24:mi:ss format 
Suggest default to current date/time 
Time in hh24:mi:ss format 
Suggest default to 31-DEC-2037 
23:59:59 

* Currency Code 

CUR_CURR_CD 
Varchar2(3) Must be 
provided. Can be retrieved or 
validated based on station's 
currency for station level 
Rates_Header, or owning country 
for location hierarchy level 
Rates_Header. 
"D" for SI retail 

"B" for Bid Pricing NatRes rates 
Valid values "P" and "S" 
Indicates if discount may be 
applied to underlying rates. 
"Y" - Rates may be discounted "N" 
- Rates cannot have discount 
applied. 

Denormalized from product 
instance 

Denormalized from product 
instance 

Denormalized from product 
instance 

Denormalized from product types 
Time in hh24:mi:ss format 
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* Bolded fields represent attributes for Rates Header entity that are required for iteration 2. 

* Fields marked by an asterisk are denormalized from the source indicated in the Remarks column. 
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VRS Rate Detail Usages 

The rate detail usages table row is created upon successful generation of a rate header record. Generation of the rate 
detail usage row is totally transparent to the end user. 

Column Description Column Name Data Type Remarks 


#Rate Header Identifier 
Rate Header Identifier Ref 

Reservation Start Date 

Reservation End Date 

Rental Start Date 

Rental End Date 

#Record Create Date and Time 
Record Creation Operator 


RHjmiJUNIQJD Number(15) 
RHJRTHJJNIQJDJREF Number(15) 


Copied from corresponding rate 
header. Describes rate header that 
"owns" this row. 
Copied from corresponding rate 
header. Describes rate header that 
"owns" the rate detail that will be 
used by this rate header. 
Set to value contained in 
EFFC__STARTJ>T field of 
corresponding rate header 
Time portion is in hh24:mi:ss 
format 

Set to value contained in 
EFFCEND_DT field of 
corresponding rate header 
Time portion is in hh24:mi:ss 
format 

Set to value contained in 
EFFC JSTARTJDT field of 
corresponding rate header 
Time portion is in hh24:mi:ss 
format 

Set to value contained in 
EFFC_END_DT field of 
corresponding rate header 
Time portion is in hh24:mi:ss 
format 

Time in hh24:mi:ss format 


RES_STARTJDT Date 


RESJENDJDT Date 


CO_STARTDT Date 


COENDDT Date 


CREATE JDT Date 
CREATEOPER Varchar2(32) 


*Bolded fields represent mandatory attributes for Rate Detail Usage entity. 

Every rate header record will have at least one rate detail usages entry. The rate detail usages specifies which rate 
header "owns" the rate detail that the VRS rates engine will retrieve to calculate time and mileage charges for a 
particular rental. 
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VRS Rate Header Oual Assn 

The rate header qual association table row is created upon successful generation of a rate header record. Generation 
of the rate header qual association row is totally transparent to the end user. 


pi 

fas." 

o 

Hi 


ill 
□ 


Column Description 


Column Name 


Data Type Remarks 


#Rate Header Qual Identifier RHQA_ UMQJD 


Rate Header Identifier 


Rate Qual Code 


Reservation Start Date 


Reservation End Date 


Rental Start Date 


Rental End Date 


RHJITHJJNIQJD 


Number(15) 
Number(15) 


RDB_DRTNJBND_CD Number(6) 


RES START DT 


Date 


RES END DT 


Date 


EFFC START DT 


Date 


EFFC END DT 


Date 


Record Create Date and Time CREATE J)T 
Record Creation Operator CREATE_OPER 


Date 

Varchar2(30) 


Generated by RHQA sequence 

number generator 

Copied from corresponding rate 

header. Describes rate header that 

"owns" the this row. 

Identifier of qual selected from rate 

qual pick list 

Set to value contained in 

EFFC_START JDT field of 

corresponding rate header 

Time portion is in hh24:mi:ss 

format 

Set to value contained in 
EFFC_END_DT field of 
corresponding rate header 
Time portion is in hh24:mi:ss 
format 

Set to value contained in 
EFFC_STARTJ)T field of 
corresponding rate header 
Time portion is in hh24:mi:ss 
format 

Set to value contained in 
EFFC_ENDJDT field of 
corresponding rate header 
Time portion is inhh24:mi:ss 
format 

Time in hh24:mi:ss format 


*Bolded fields represent mandatory attributes for Rate Header Qual Association entity. 

The rate header qual association row specifies which rate qual is associated to the header for the dates and times 
provided. The Rate Header Qual Assn entry is optional. If no entry is found for the reservation and rental dates, no 
restrictions apply. 
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2,1.2.1.1.1 Example 1 - Create Rate Header for Limited Mileage Product 


Given: 

A limited mileage ("medium free miles per day") retail product is to be made available at branch 0109. It 
will be available for reservation as soon as rates are defined. Based on future plans for club and association 
discounts, it is decided that the underlying rates can be discounted No fuel, taxes, or surcharges will be 
bundled with the product. The product will offer 150 free miles per day. 

User Input: 


R 


Standard Retail Rates 


RLLM 


Retail Limited Medium Free Miles 


LIMMED 


Local Market Medium Free Daily Miles 


Product LIMMED is selected. The product code can be entered directly or by using the pick lists and 
scoping available on the user interface. (Optional scoping by product type and family shown) 


0109 

T 

ATY_BRANCH 

T 


20-MAY-2001 


31-DEC-2037 


U 


User enters (or selects from pick list) location for rate header (branch 0109) 
User accepts default effective start and end dates 


5! 

|as3s 

ill 


Retail - 150 Free Miles/Day 


User enters a location specific description of the product offering 


D 


User enters "D" for rate base unit 

User enters a "Y" indicating rates can be discounted 

User enters "P" to mark this as the primary retail rate at branch 0109 


000001 


Daily Rental, Maximum 30 Days 


User selects appropriate rate qual from pick list 
User attempts to save new rate header 


System Response: 

The data maintenance process verifies a user defined area name 0109 with type "ATY_BRANCH" exists. If 
no UDA exists, return error message and halt creation process. 


Last Save Date:l 1/5/2001 10:18 AM 
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System Response (Continued): 


The data maintenance process searches rate header table for an existing entry for product LIMMED at 
branch 0109 where the effective start and end dates overlap the input dates (20-MAY-2001, 3 l-DEC-2037) 
in some way. If existing rate header found, return error message and halt creation process. 

The data maintenance process checks for another active rate header with product type "R" at branch 0109 
being flagged as primary. If an existing primary rate exists , return error message and halt creation process. 
If no other active rate header of the given product type is active at this location, primary rate 
indicator is set to "P". 

The data maintenance process retrieves product type code, product family code, tax, surcharge, and fuel 
inclusive flags from other product tables based on input product instance code and location. 

The data maintenance process retrieves next rate header sequence number to assign from Oracle rates 
header sequence generator. If sequence number is not successfully retrieved, return error message and halt 
creation process. 

The data maintenance process populates creation operator ID and creation date/time and inserts new rate 
header record 

If rate header successful, data maintenance process formats and inserts new rate detail usages record 

If rate detail usages insert successful, the data maintenance process retrieves next rate header qual 
association sequence number to assign from Oracle rates header qual association sequence generator. If 
sequence number is not successfully retrieved, return error message and halt creation process. 

Data maintenance process formats and inserts new rate header qual association record 

If creation and insert of rates header, rate detail usages, and rate header qual association were successful, 
data maintenance process issues database commit and returns success. If any insert foils, the data 
maintenance process issues database rollback and returns appropriate failure message. 
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2.1.2.1.1.2 Example 2 - Create Rate Header for a Weekend Sp ecial 
Given: 

A weekend special retail product is to be made available at branch 0109. It will be available for reservation 
as soon as rates are defined. The associated rates can be discounted No fuel, taxes, or surcharges will be 
bundled with the product. The product will offer 1 50 free miles per day. 

User Input: 


Special Rates 


WSRT 


Weekend Special 


WSLMRT 


Weekend Special Local Market 


Product WSLMRT is selected. The product code can be entered directly or by using the pick lists and 
scoping available on the user interface. (Optional scoping by product type and family shown) 


0109 

T 

ATYJBRANCH 

T 


20-AUG-2001 


31-DEC-2037 


User enters (or selects from pick list) location for rate header (branch 0109) 
User accepts default effective start and end dates 


Weekend Special Branch 0109 


User enters a location specific description of the product offering 


D 


User enters "D" for rate base unit 

User enters a "Y" to allow the rates to be discounted 

User enters "P" to mark this as the primary retail rate at branch 0109 


000002 


Weekend Special Noon Thurs Pickup 


User selects appropriate rate qual from pick list 
User attempts to save new rate header 
System Response: 

The data maintenance process verifies a user defined area name 0109 with type "ATY_BRANCH" exists. If 
no UDA exists, return error message and halt creation process. 
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System Response (Continued): 


The data maintenance process searches rate header table for an existing entry for product WSLMRT at 
branch 0109 where the effective start and end dates overlap the input dates (20-AUG-2001, 3 l-DEC-2037) 
in some way. If existing rate header found, return error message and halt creation process. 

The data maintenance process checks for another active rate header with product type "S" at branch 0109 
being flagged as primary. If an existing primary rate exists , return error message and halt creation process. 
If no other active rate header of the given product type is active at this location, primary rate 
indicator is set to "P". 

The data maintenance process retrieves product type code, product family code, tax, surcharge, and fuel 
inclusive flags from other product tables based on input product instance code and location. 

The data maintenance process retrieves next rate header sequence number to assign from Oracle rates 
header sequence generator. If sequence number is not successfully retrieved, return error message and halt 
creation process. 

The data maintenance process populates creation operator ID and creation date/time and inserts new rate 
header record 

If rate header successful, data maintenance process formats and inserts new rate detail usages record 

If rate detail usages insert successful, the data maintenance process retrieves next rate header qual 
association sequence number to assign from Oracle rates header qual association sequence generator. If 
sequence number is not successfully retrieved, return error message and halt creation process. 

Data maintenance process formats and inserts new rate header qual association record 

If creation and insert of rates header, rate detail usages, and rate header qual association were successful, 
data maintenance process issues database commit and returns success. If any insert fails, the data 
maintenance process issues database rollback and returns appropriate failure message. 


Last Save Date: 11/5/2001 10:18 AM 


Page 40 of 114 


Consolidated Products and Rates Design J3 


c 

© 


© 

ft 

k 

« 

s 


© s 
Oh 


^ © 

© © 

3 C 

s « 

> s 


2 

3 

A 

T3 
S 

2 


ft 

© 

t© 
IB 
&3 


3 I 


o 
c 

"3 

g 

<u O 


CO 


C/3 


« tc © 

w © 5- 


© 

5 « 


OS 
«o 

On 
in 

rn 
cN 
r- 
m 
o 

CN 

u 

8 

I 


CN 
CN 

O 
<N 


O 

o 
cn 

6 

I 

o 

CN 


X 

u 

5 


s 


© 
U 


C3 


2 
« 

mm 

© 

O 

3 
© 

u 


08 

Q 

© 

© 
U 

U 


© 

3 


CO £ 


S 1 


s 

3 

S CJD 

.22 w 


© fli 

B « S 

fi5 CO £5 


CN 
(N 

O 
CN 


O 

o 

CN 

6 

i 

O 


<D 


I 

S 
I 

1 
o 

2 

g 1 


<2 


I 

ft 
■s 
c 

c 


© 
« 

ft 

u 


3 


ft 
3 

3 
© 


© 
© 


© 
3 
ft 

mm 

3 

3 

© 


© 

& 


© 

l 


© 

3 


On 
f) 
6< 
*n 

CO 
CN 
t> 

o 

CN 
i 

CJ 

w 

Q 
i 

f— i 
on 


CN 
CN 

O 
CN 


O 

o 

3 

o 

CN 


Os 

*o 

OS 

CN 

t> 
CO 

o 

CN 
i 

U 

w 
9 


CN 
CN 

o 

CN 


o 
o 

CN 

6 
-? 

O 

CN 


s 

3 
© 

c 
O 

© 

Z 

u 


5 

3 
Q 

© 

3 

© 
fa. 


o 
o 

1 


CN 
CN 

© 

CN 


O 

o 

CM 

6 

< 
t 

o 

CN 


3 

•f— t 

Vi 

Q 

C 

8 
1 


CO) 
03 

A, 


< 

oo 


o 
o 


i 

Q 

00 


,3 


e 

W 

I 


OS 

*n 

co 
<N 

r* 

<o 
O 
CM 
i 

o 
w 


ro 


jjisa 


o 


a? 

i 


a 

1 


e 


« 

Q 

■a 
s 

W 

B 

O 

! 


o 

CO 

s 

o 

i 


OS 


-o 
o 
U 
s 
.2 

OS 

s 

& 


J 


-33 


CM 
CM 

o 

CM 


© 
o 

CM 
I 

a 

% 

o 

CM 


ON 
ON 

<n 

rn 
CN 

CO 

o 

CM 

6 
w 

9 

CO 


CM 
CM 

o 

CM 


o 
o 

a 

D 
< 
o 

CM 


&2 

1 8 
OS c 


CM 


CO 


2 

• 1-1 

o 

Q 

I 

Pi 

•o 

! 

s 

'o 

CO 

§ 


O 

CO 

p- 


fa. 




OS 


La 


4) 


a 


0 

O 

41 

o 


* 

O 


S- 


o 



CM 


CM 


O 


CM 






r— 1 


o 
o 

eg 

CM 

Q 

I 

a 

o 

+•» 




y 

o 

CM 


< 

oo 


o 
o 


Q 

1 

CO 

3 


perotsystems 


2.L2.1.1.3 Example 3 - Create Rate Header for Bid Pricing Rate 
Given: 

A retail product using Bid Price rates is to be made available at branch 01 10. It will be available for 
reservation as soon as rates are defined The associated rates may be discounted. Based on future plans for 
distribution channel discounts, it is decided that the maximum discount that can be applied to this product at 
branch 0109 is 20%. No fuel, taxes, or surcharges will be bundled with the product. The product will 
unlimited free miles. 


User Input: 


ru 
B 

sj 


[naa 

111 

ru 

i 3 


R 


Standard Retail Rates 


BIDR 


Bid Price Retail Rates 


BH3RTL 


T Bid Price Retail Product 


Product BIDRTL is selected. The product code can be entered directly or by using the pick lists and 
scoping available on the user interface. (Optional scoping by product type and family shown) 


0110 

T 

ATYJBRANCH 

T 


20-AUG-2001 


31-DEC-2037 


User enters (or selects from pick list) location for rate header (branch 0110) 
User accepts default effective start and end dates 


Bid Price Rate Branch 01 10 


User enters a location specific description of the product offering 


B 


User enters "B" for rate base unit 

User enters a "Y indicating associated rates may be discounted 
User enters "P" to mark this as the primary retail rate at branch 0110 

No rate qual is attached to this rate header 

User attempts to save new rate header 


System Response: 

The data maintenance process verifies a user defined area name 0110 with type "ATYJBRANCH" exists. If 
no UDA exists, return error message and halt creation process. 


Last Save Date:l 1/5/2001 10:18 AM 
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System Response (Continued): 

The data maintenance process searches rate header table for an existing entry for product BIDRTL at 
branch 01 10 where the effective start and end dates overlap the input dates (20-AUG-2001, 31-DEC-2037) 
in some way. If existing rate header found, return error message and halt creation process. 

The data maintenance process checks for another active rate header with product type "R" at branch 0110 
being flagged as primary. If an existing primary rate exists , return error message and halt creation process. 
If no other active rate header of the given product type is active at this location, primary rate 
indicator is set to "P". 

The data maintenance process retrieves product type code, product family code, tax, surcharge, and fuel 
inclusive flags from other product tables based on input product instance code and location. 

The data maintenance process retrieves next rate header sequence number to assign from Oracle rates 
header sequence generator. If sequence number is not successfully retrieved, return error message and halt 


□ creation process. 


The data maintenance process populates creation operator ED and creation date/time and inserts new rate 
m header record 


If rate header successful, data maintenance process formats and inserts new rate detail usages record 

If rate detail usages insert successful, the data maintenance process retrieves next rate header qual 
association sequence number to assign from Oracle rates header qual association sequence generator. If 
sequence number is not successfully retrieved, return error message and halt creation process. 

*]: If creation and insert of rates header, and rate detail usages were successful, data maintenance process 

W J issues database commit and returns success. If any insert fails, the data maintenance process issues database 

O rollback and returns appropriate failure message. 


Last Save Date; 1 1/5/2001 10:18 AM 


Page 44 of 114 


Consolidated Products and Rates Design J3 


3 = 

yj 

flJ 
I1J 


c 

g 


u 

p 

Szj 


11 


3 5 

© -g 


1 

P 
s 

> 
£ 

63 


« 

P 

■*-» 

CO 


II 


o 
<— ■ 

S3 

i-H 

*- » 

o2 

o 

a* 
"a 

• iH 


a! 
Q 


c4 


-a 

p p 


a 


o\ 
m 

cK 
in 

CM 

r- 

O 
CN 
i 

u 
w 


m 
o 

do 


O 
O 

a 

o 

CN 


"8 P 


ON 


p 


o 

c 

O 

co 

u 


o 
o 

CM 


a 

CO 
P 

CO 

u 


en 
o 

66 


o 
o 

CN 
i 

a 

i 

o 

CN 


s 

"3 

3 

fa 


CO " 


§ OX 

.52 « 
P fa 


ce 


•§1=5 


fl s c 
CSJ 09 3 


5 
-a 

2 
2 


i 

2 

« 

^— > 
C 

a> 

CO 

a. 

1 

so 

I 



o\ 


*o 


dK 


in 

ate 

V N 

P 

t> 


o 

s 



t 

U 

"3 

w 

Rent 

Q 
i 


m 


o 






00 

P 

i— < 

1m 

»— i 

o 

$ 

o 


<N 


i 

O 

ntal 

•AU 

Re 

o 

<N 

o 

ON 



OS 

p 

c< 
«n 

tJ 


s 

CN 

&3 


e 

CO 

o 

.2 


rvai 

EG 


a 

Re 

CO 


en 

ce 

o 

P 


■*■> 

00 

u 


1—1 

VI 


[ion 

o 
o 

CN 
i 

O 



D 

en 

< 

Re 

o 

CN 

«m 


e> 




IB 


u 






CO 





ON 

p 






o 




ce 


« 


S3 

ON 




2 


S 






a 


O 

I—* 

o 


o 

CN 



2 



1 

u 



m 


o 


m5 




00 






o 
o 

CO 

CN 

p 

i 

a 


D 

C8 




CN 


CO 


& 

o 

•8 

2 
a. 

-a 
i 

"o 

c 
o 

u 


o 
m 


oo 

o 


o 
o 

in 


Q 

C75 


2.1.2.1.2 Scenario Extensions 

2.1.2.1.3 Scenario Variations 


2.1.2.1.3.1 User Updates Rates Header 

A number of fields on the rate header are potentially available for update. Each of these fields are 
discussed below. Any successful update will result in the data maintenance process setting the update 
operator and date values appropriately and committing the change. 

2.1.2.1.3.2 Rate Header Description 

The rate header description may be updated as business conditions warrant (i.e. free mileage limit on 
medium mileage rate changes from 150 to 100 per day). The user overtypes the existing text and 
saves the record. 

2.1.2.1.3.3 Primary Rate Indicator 

The primary rate indicator may be updated. If the indicator is set to "P" 5 the data maintenance process 
must check for any other products of the same type at the same location also flagged as <P>rimary. 

If an existing primary rate is located, the user is given the choice of continuing with the update or 
canceling it If the user chooses to continue, The existing record is updated and it's primary indicator 
is set to "S". The record updated by the user has it's primary indicator set to "P" and both changes are 
committed. If the user chooses to cancel the update, the primary indicator on the updated record is set 
to it's initial value and no updates take place. 

2.1.2.1.3.4 Effective End Date 

The effective end date of the rate header represents the last date and time that a reservation may be 
taken for the product and location represented by the rate header. Effective end date can be updated to: 
♦ Any valid date that is less than the current value of effective end date.(Effective end date cannot be 
extended) 

. Any valid date that is greater than or equal to the current date (effective end date cannot be back- 
dated). 

If the effective end date is set to the current date, the time portion is set to current time. If the effective 
end date is set to a future date, the time portion is set to 23:59:59. 

End dating a rate header is one way of discontinuing a product offering at the given location. 
Regardless of the dates on any tables associated to the rate header (rate detail, rate quals, etc.), once 
the rate header is inactive (inactive being defined as having an effective end date in the past), all 
associated data is also considered inactive. 

Before the data maintenance process allows a rate header to be end dated, it must first verify that no 
other rate headers are sharing or referencing the rates of the rate header being end dated. 

2.1.2.1.3.5 User Deletes a Rate Header 

The user cannot delete a rate header. Rate headers can be end dated to discontinue the product 
offering (see rate header updates above). 

2.1.2.1.4 Related Information 
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2.1.2.1.5 References/Appendix -A 

Data Model for VRS Rates Header 

Product Type, Product Family, Product Instance, Rate Header, and User Defined Area Relationships 

Rate Header, Rate Header Qual Association, Rate Qual, arid Rate Detail Usages Relationships 


Prods 

#*PROD_ID 
PROD_DESC 
PRT PROD TYP CD 

-i 

5 

i 

o 

X 

Prod Insts 


X>— PRD_OF- 


r Prod Tvds 

#*PROD TYP CD 
* PROD TYP DESC 


s **PROD INST CD 
ffj PRD PROD ID 

CRY AR1MP CRY^CD 
PROD INST DESC 
i4f CREATE USERJD 

CREATE DT 
\l% CUR CURR CD 
" o VER NBR 
t AIRLINEJHCKET REQDJND 
b AUTH STAT 

AUTO_RECMPT_RT 
o BEST_RT_FLG 
sj COMPANY_CD 
o COM_FLG 
J> CO_STRT_DT 
0 FREE_VHCL_COLL 
$ FREE VHCL_DLVR 
% FUEL INCL FLG 
f> GTEE_RT_IN D 
* GUAR_DAYS NBR 
$ MAX_COM_RT 
o ONE_WAY ONLY 
o PREF_CHANJND 
o RES STRT DT 
o RT BASE_UNfT_CD 
0 SEC RATE IND 
o AUTH*_DT 
o AUTH USR 
o CO_END DT 
o CPL PLAN ID 
o CRS STAT 
o DBG_BNDJD 
o DSCNT_FLG 
o EXR TYP CD 
o FF fVL_FLG 
o MAX DSCNT RT 
oMIN RNT DAY_FOR DOM 
o MIN RNT DAY_FOR_INT 
o PRI RANK IND 
o PRODJJSG STAT 
o RES CHNG FLG 
o RES END_DT 
o SALE_TX_INCL FLG 
o SELF_SVCJND 
oUNBLD FU£L_RENT AMT 
o SCHGJNCL FLG 
o LAST UPDT_USERJD 
oLAST_UPDT DT 
o IPC CPL_PLANJD 


r 


-RH_UDA_FK 1 


RH_PRODJNSTS_FK. 


Rates Header 


#*RTH UNIQ ID 
CREATE_DT 
CREATE OPERJD 
CUR CUR CD 
EFFC END_DT 
EFFC_START_DT 
PRC PROD INST_CD 
PROD ID 

RT BASE UNIT_CD 
MAX DSCNT RT 
SALES TX INCL FLG 
UDA AREAJD 
SCHGJNCL_FLG 
UDA_ATY_AREA_TYP 
PRIM_RATEJND 
RATEJHEADER DESC 
PROD TYP CD 
FUELJNCL_FLG 
o A!RLINE_TiCKET REQDJND 
o LOCAL ONEWAY IND 
o BEST_RT_FLG 
o RATE TYPE IND 
o SEC_RATE IND 
OVER NBR 
o D!FF_APPLY FLG 
o DSCNT_FLG 
o EXR TYP CD 
o LST CHG_DT 
OLST CHG USR 
o ONE_WAY_ONLY 
o PRI RANK IND 
o PROD^USG STAT 
o RES_END_DT 
0 SPEC CTY FLG 
o STN_STNJD 
o BLD PROD_FLG 
o DISC TYPEJND 
VREC IND , 


r Msr.Dfnd ..Areas 

#*ATY AREA_TYP 
#*AREA_ID 
* AREA_DESC 
o INV_CNTL IND 


c 

D 


i 


r gta Uda 

#*AREAJD2 
#*AT Y_A R E A_T Y P 2 
#*STN ID1 
#*EFF_START_DT 
O EFF EN D_DT 
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Rate Header Qua! Assn 

#*RHQA UNIQ ID 

* RH RTHJJNIQJD 

* RDB_DRTN_BN D_CD 

* RES_END_DT 

* RES_START DT 

* EFFC_END _DT 

* EFFC_STARTJ3T 

* CREATE_DT 

* CREATEJDPER 
o UPDTJDT 

o UPDT OPER 


-Assoc Qual- 


Owns 


Rates Header 

#*RTH_UNIQ ID 
PRODJYP CD 
PRC_PRODJNST_CD 
PRODJD 
UDA^AREAJD 
UDA ATYAREAJTYP 
EFFC_END_DT 
EFFC_START_DT 
RT_BASE JJN IT_CD 
RATE HEADER DESC 
PRIMJRATE IND 
CUR_CUR_CD 
MAX_DSCNT_RT 
SCHG INCL_FLG 
SALES JTX INCLJLG 
FUEL INCLJFLG 
CREATE_DT 
CREATE_OPERJ D 
o AIRL1NEJT!CKET_REQDJND 
o LOCAL ONEWAYJND 
o BESTRTJLG 
o RATE TYPE IND 
0 SEC_RATE IND 
o VER_NBR 
o DIFF_APPLY_FLG 
o DSCNT_FLG 
0 EXR_JYP_CD 
0 LST_CHG_DT 
o LST_CHG USR 
o ONE_WAY ONLY 
o PRLRANK IND 
o PROD_USG_STAT 
o RES END DT 
o SPEC CTY FLG 
o STN JjTNJD 
o BLDJPROD_FLG 
o REC IND 


-Owns- 


-Uses Rates Owned By- 


RNT DRTN BNDS > 

#* DRTN BND_CD 
CHGJJNIT_CD 
DRTN_BND_DESC 
MIN_RNTJDRTN 
MIN_RNTN_DRTN_UNIT_CD 
MAX_RNT DRTN 
MAX_RNTN_DRTN_UNIT CD 
O CI BY 
o C!_DAY_OF_WK 
o CO_END_DAY 
o CO_FROM 
o CO_STRT_DAY 
o COJJPTO 
o CREATE_USERJD 
o CREATEJDT 
o EXCLJDAYS STR 

o incl_days_str 

0 req_ovnt_str_desc 

o CHECKIN LATESTJ3T 
0 EXCL DAYSJ/1ASK 
o 1NCLJDAYS MASK 
0 MAX RNT_DRTN_EXTRA 
o MINCHG_FRi_NBR 
0 MIN CHG MON NBR 
0 MIN_CHG_SAT_NBR 
o MIN_CHG SUNJMBR 
O MIN.CHG THU NBR 
o MIN_CHG_TUE_NBR 
o MIN_CHG WEDJslBR 
O RDB DRTN BND_CD_EXT 
o REQJ3VNT MASK_NBR 
o ADV.BKGFLG 
0 PREPAY CNDS FLG 


Rate Detail Usages 

^#*RH_RTH_UNIQJD 

* RH.RTH UN!QJD_REF 

* RES_START_DT 

* RES_END_DT 

* CO_STARTJDT 

* COJ5ND_DT 
#*CREATE_DT 

* CREATE__OPER 
o UPDATE JDT 
o UPDATE OPER 


J 
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2.1.2.2 Use Case: User Creates Reservation Applicability 

VRS reservation applicability allows the user to define which distribution channels (Voice, Web, GDS 5 Branch, etc.) 
are eligible to reserve a given product for pick up at a specified level of the rates hierarchy. When a reservation is 
made, the VRS pricing engine checks the input reservation source and pick up location against the reservation 
applicability table and verifies that it is eligible to reserve the requested product. 

No distribution channel hierarchy or rates hierarchy traversal is performed for reservation applicability. The rates 
engine takes the product code, user defined area name, and user defined area type from a candidate rate header and 
searches for an exact match in the reservation applicability table based the distribution channel passed by the caller. 
This approach to reservation applicability is similar in concept to the way reservation applicability is implicitly 
implemented in the existing NatRes system using the NR150P discounts file. Appendix A provides a number of 
scenarios to illustrate the concept. 

Every product instance can have one or more entries associating valid reservation sources with the product. 

Create the entries necessary to allow a product to be reserved by 
distribution channels appropriate for the product. When the task is 
complete, the appropriate data will be added to the PROD_AVLS table. 
This Use Case deals with Create activity on the VRS reservation 
applicability table. (PROD_AVLS). 

Product instance table populated. Distribution channels table defined 
and populated. Associated rates header created. 
Reservation applicability created. 

Reservation applicability not created successfully 

User responsible for maintaining reservation applicability data (Super 
User). 

New reservation applicability is created. 


The steps to creating reservation applicability for a standard retail product are shown below. 
Step 1: User specifies product instance 

User specifies the product instance that the availability rule will be associated with. The product instance 
specified must already exist in the product instance table (PROD JNSTS). 

Step 2: User specifies availability 

User chooses the distribution channel(s) from a pick list that contain valid reservation channels 
Step 3: User specifies valid start and end dates 

User provides the date range that the input reservation applicability record will be valid for. Input effective 
start date must be greater than or equal to current date. Input effective end date must be greater than input 
effective start date. Suggest a default of current date (effective start date) and 3 l-DEC-2037 (effective end 
date). 


[ij Goal In Context: 


5 S 

\*4 


PS 


Scope: 
Level: 

Pre-Condition: 


Success End Condition: 
fy Failed End Condition: 

-if Primary Actor: 

Trigger Event: 


2.1.2.2.1 Main Success Scenarios 


Last Save Date: 1 1/5/2001 10:18 AM 


Page 49 of 114 


Consolidated Products and Rates Design J3 


rent-a-car 


perotsystems 


o 

111 

IB 


w 


SSE S 

IV 


Step 4: User specifies rate hierarchy location 

User provides user defined area name and type that the entry is applicable for. The UDA name and type 
entered will be matched against the user defined area name and type established on a rate header for the 
given product. 

Step 5: User saves record. 

Step 6: System Validates input distribution channel 

Return error if invalid 

Step 7: System retrieves Rate Header ID based on input Product Instance code and UDA name and 
type 

Return error if not found 

Step 8: System retrieves product availability sequence number 
Step 9: System saves record 

The input record is written to the PROD_AVLS table. The primary key for this record is the sequence 
number prod_avls_id. 


Column Description 

Column Name 

Data Type 

Product Availability Sequence Number 

prod avl id 

NumberQ 

Product Code 

pre _prod inst cd 

Varchar2(8) 

Availability type <R>eservation 

avl for 

Varchar2(l) 

User Defined Area Name 

uda area id 

Varchar2(10) 

User Defined Area Type 

uda aty area type 

Varchar2(10) 

Reservation start date of availability record 

effc start dt 

Date 

Reservation end date of availability record 

effc end dt 

Date 

Rate Header Unique Identifier 

Rh rth uniq id 

Number (1 5) 

Distribution Channel 

dist chan id 

Varchar2(8) 

Include/Exclude indicator <I> nclude 

incl_stat 

Yarchar2(l) 
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2.1.2.2.1.1 Scenario 1: User creates new product availability 


The following data is provided by a user to create product availability: 


Product Instance Code: 
Distribution Channels: 
Effective Start Date: 
Effective End Date: 
UDA Area ID: 
UDA Type: 


LIMMED 

Reserve from any Rental Branch 

01-JUN-2001 

Ongoing 

01 

GROUP 


The goal is to make the LIMMED product defined for Group 0 lavailable for reservation from any branch in 
the United States. This entry will apply to the rate header defined for the LIMMED product defined for 
Group 01 only. 


D 

n 


|lJ 

X1S! 8 

jj'3 8 


!*1 


R 


Standard Retail Rates 


RLLM 


Retail Limited Medium Free Miles 


LIMMED 


Local Market Medium Free Daily Miles 


User selects product LIMMED from list of valid domain values 


01 

T 

ATY_GROUP 

T 


User selects user defined area defining geographical scope of the new row (Group 01). 


Branch 


Rental Branch 


Include 


R 


Reservation 


User selects distribution channel from list of valid domain values 
User Selects to Include for Reservation 


01-JUN-2001 


31-DEC-2037 


User Sets Start date to June 1, 2001 
User accepts default end date 

User saves record 

System validates user input 

System retrieves next sequence number 

System populates defaults 

System writes new record 
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The following record represents a row in the reservation applicability table (PROD_AVLS): 


Avail 
ID 

Product 
Code 

Avail 
Type 

Uda Area ID 

Uda Aty Area 
Type 

Effc Start 
Date 

Effc End 
Date 

0000001 

LIMMED 

R 

01 

ATY GROUP 

01-JUN-2001 

31-DEC-2037 


Rate 

Distributi 

Include/ 

Header 

on 

Exclude 

Unique 

Channel 


ID 



000000001 

Branch 

I 


2. 1 .2,2. 1 .2 Scenario 2: Create Reservation applicability for a Bid Price Product 
The following data is provided by a user to create a product availability: 


Product Instance Code: BIDRTL 

Distribution Channels: Available for Reservation through the GDS', Voice Reservations, 

and Web 

UDA Area ID: 0110 

UDA Type: BRANCH 

Effective Start Date: 01-JUN-2001 

Effective End Date: Ongoing 


R 


Standard Retail Rates 


BIDR 


Bid Price Retail Rates 


BIDRTL 


Bid Price Retail Product 


User selects product BIDRTL from list of valid domain values 


0110 

▼ 

ATYJBRANCH 

▼ 


User selects user defined area defining geographical scope of the new row (Branch). 


GDS 


GDS 


I 


Include 


R 


Reservation 


User selects distribution channel from list of valid domain values 
User Selects to Include for Reservation 


01-JUN-2001 


31-DEC-2037 


User Sets Start date to June 1, 2001 
User accepts default end date 
User saves record 
System validates user input 
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System retrieves next sequence number 
System populates defaults 
System writes new record 


The following figure represents the data in the reservation applicability table (PROD_AVLS) : 


Avail 
ID 

Product 
Code 

Avail 
Type 

Uda Area ID 

Uda Aty Area 
Type 

Effc Start 
Date 

Effc End 
Date 

0000001 

LIMMED 

R 

01 

ATY GROUP 

01-JUN-2001 

31-DEC-2037 

0000002 

BIDRTL 

R 

0110 

ATY BRANCH 

01-JUN-2001 

31-DEC-2037 


Rate 

Distributi 

Include/ 

Header 

on 

Exclude 

Unique 
ID 

Channel 


000000001 

Branch 

I 

000000009 

GDS 

I 


* Bolded fields represents new entry in the table 

The process is repeated for the internet and voice reservation distribution channels. After these two entries are 
created, the PROD_AVLS table will contain the data shown in the figure below: 


Avail 

Product 

Avail 

Uda Area ID 

Uda Aty Area 

Effc Start 

Effc End 

ID 

Code 

Type 


Type 

Date 

Date 

0000001 

LIMMED 

R 

01 

ATY GROUP 

01-JUN-2001 

31-DEC-2037 

0000002 

BIDRTL 

R 

0110 

ATY BRANCH 

01-JUN-2001 

31-DEC-2037 

0000003 

BIDRTL 

R 

0110 

ATY BRANCH 

01-JUN-2001 

31-DEC-2037 

0000004 

BIDRTL 

R 

0110 

ATY BRANCH 

01-JUN-2001 

31-DEC-2037 


Rate 

Distributi 

Include/ 

Header 

on 

Exclude 

Unique 

Channel 


ID 



000000001 

Branch 

I 

000000009 

GDS 

I 

000000009 

Web 

I 

000000009 

Voice 

I 


* Bolded fields represent new entries in the table 
2.L2.2.2 Scenario Extensions 
2.1.2.2,3 Scenario Variations 
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2.1 .2.2.3 . 1 User Updates Reservation Applicability 

The only information that can be updated for an existing reservation applicability record is the 
effective end date. The reservation applicability record is invalid after the effective end date. The 
effective end date may be set to any valid date that is less than the existing effective end date and not 
less than the greater of either the effective start date or the current date. New reservation applicability 
records can be added at any time. 

2.1.2.2.3.2 User Deletes Reservation Applicability 

A user does not have the ability to physically delete an existing reservation applicability record. 

2.1.2.2.4 Related Information 

2.1.2.2.5 References/Appendix -A 

The following examples demonstrate how VRS reservation applicability will function. 
Given 


Rate Header Data 


Header 
ID 

User 

Defined 

Area 

UDA 
Type 

Effective Start Date 

Effective End Date 

Product 
Instance 

1 

01 

ATY_GROUP 

20-MAY-2001 14:20:22 

31-DEC-2037 23:59:59 

LIMMED 

2 

01A 

ATYJREGION 

20-MAY-2001 14:20:29 

31-DEC-2037 23:59:59 

LIMMED 

9 

0110 

ATY_BRANCH 

20-AUG-2001 18:46:03 

31-DEC-2037 23:59:59 

BIDRTL 


Prod 
Type 

Prod 
Family 

Rate Header Description 

R 

RLMM 

Retail Group 01 -150 
Free Miles/Day 

R 

RLMM 

Retail Region 01A- 
150 Free Miles/Day 

R 

BIDR 

Bid Price Rate Branch 
0110 
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Reservation Applicability Data 


b 

Hi 

S 5a" 


Avail 

.TX ▼ All 

ID 

Product 
Code 

Avail 
Type 

Uda Area ID 

Uda Aty Area 
Tvpe 

Effc Start 
Date 

Effc End 
Date 

0000001 

LIMMED 

R 

01 

ATY GROUP 

01-JUN-2001 

31-DEC-2037 

0000002 

BIDRTL 

R 

0110 

ATY BRANCH 

01-JUN-2001 

31-DEC-2037 

0000003 

BIDRTL 

R 

0110 

ATY BRANCH 

01-JUN-2001 

31-DEC-2037 

0000004 

BIDRTL 

R 

0110 

ATY BRANCH 

01-JUN-2001 

31-DEC-2037 





Rate 
Header 
Unique 
ID 

Distributi 
on 

Channel 

Include/ 
Exclude 


000000001 

Branch 

I 

000000009 

GDS 

I 

000000009 

Web 

I 

000000009 

Voice 

I 


*|5 
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2.1.2.2.5.1 Scenario 1 


Reservation call: 


Rate Header Candidate: 


Reservation Applicability: 


Reservation request is made for a retail product for pick up at branch 0110, 
Reservation source is rental branch. 

Branch 01 10 is a member of group 01. Branch 01 10 is not a member of Region 
01 A. The rate header defined for product LIMMED at location 01 
ATY_GROUP is selected. 

The reservation applicability table is searched using the input distribution 
channel representing a rental branch, product LIMMED, user defined area name 
01 and user defined area type of ATY_GROUP> A matching entry is found, so 
the product may be offered. 


IrJ 


ill 

m 


m 


3 'Hi' 

m 
M 


2 A. 22.5 2 Scenario 2 


Reservation call: 


Rate Header Candidate: 


Reservation Applicability: 


Reservation request is made for a retail product for pick up at branch 0163. 
Reservation source is rental branch. 

Branch 0163 is amember of group Ol.Branch 0163 is amember of Region 01A. 
The rate header defined for product LIMMED at location 01 A ATY REGION is 
selected. 

The reservation applicability table is searched using the input distribution 
channel representing a rental branch, product LIMMED, user defined area name 
01 A and user defined area type of ATY REGION. A matching entry is not 
found, so the product will not be offered. 

Note that the reservation applicability search required an exact match on 
distribution channel, user defined area name and user defined area type. 
No traversal of the distribution channel hierarchy or rates hierarchy was 
performed. 
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Product/Rate 

Car class definition is made up of 2 components, class and 
suffix 

118 

ChargeEngine, Coverage Engine 
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ChargeEngine 
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1.1 Overview 


The purpose of this document is to provide detailed design specifications of how the charge engine 
component of VRS will be utilized in estimating and allocating charges for the retail line of business. 
This will reflect complete design of each of the impacted areas with reference to gaps that will be 
delivered through iteration 3 of ECARS 2.0. This document is specifically for the charge engine. In 
this iteration of the project appropriate changes are made to the charge engine to enable it to 
interface properly to the modified Tax and Surcharge engines. 

m=1 .2 Dependencies 

^^Dependencies with ERAC's Test windows etc. 

I y 

m 

51.3 Data Conversion 

Sj ■ 

^High level impacts to Data Conversion. A separate document will be published for data conversion 
^design. 

Hi 

WL4 Impact Analysis 

111 

pi 

ylTbe charge engine depends on data retrieved from the database via each of the functional areas 
defined for ECARS 2.0. In general, most of the information required to generate a charge line item 
is already known. In order to minimize I/O operation to the database, the input interface is designed 
so that the information can be passed directly to the charge engine. 

1.4.1 Charge Engine 

All the charge frequencies required by ERAC are already supported by VRS except for the Coverage 
engine. Appropriate changes are needed to both the interface and service module to process a 'per 
Week' and 'per Month' rates for coverage processing. This requirement is defined in Gap 118. 

A new Tux server providing the primary ancillary charges (young renter, additional driver and after 
hour fees) must be called by the client application to obtain the required data to create a charge line 
item. That service should be called prior to calling the charge engine, when required. In cases where 
multiple instances of a charge type (such as young renter) need to be created, the calling application 
should call the service multiple times and package the data in the maimer required for the charge 
engine (See input section 3.1.1 below). This new engine has been extended to retrieve fuel pricing 
(pre-pay and post-pay) for a given ticket - the application selects one of those and passes the 
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ECARS v2.0 - Accurate Out the Door Pricing 
Detailed Design Specification 


information to the charge engine for line item generation. The Ancillary Engine design document 
provides additional details on this feature. 


u 
PI 

IS; St" 


Si 


"i IT 5' 
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2.1 Charge Engine Service 


2.1.1 Process Overview/Flow 

The VRS Charge Engine takes various rental agreement data and creates a list of line item charges for a ticket. 
These charges are returned to the user or client application via the Tuxedo Output interface described in the 
output section of this document. 


2.1.2 Detailed Design Description 

u The charge engine is a collection of 'C and Tro*C programs that perform the charge calculation 
qand where required, it calls a separate routine to allocate the charges to the appropriate payer(s). The 
q following service modules make up the charge engine proper: 


s«s?s 

w 
13 

''■a 

yj 


S W 

m 


User 
inputs 


Charge Engine Tux Entry Point 


RecalcUnit & Optimize Module 


Equipment Service Module 


Coverage Service Module 


Refuel Service Module 


lime and Mileage 


>- Discount Service Module 


Ancillary Charge Service 


Surcharges (VLF,concession,etc) 


Taxes 


Charge Engine Tux Exit Point ^^^^> Charges 


The charge engine is a Tuxedo server. Client processes interface to it directly by initializing the 
appropriate FML fields and submitting the request via a Tuxedo system call The next section 


Charge Engine Detail Design_I3 
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describes the input interface for the charge engine. For iteration 2 and 3 of the ERAC 
implementation, the interface to the charge engine will be modified to accommodate multiple vehicle 
classes so that all charges can be calculated at once. Although the Tuxedo views will be designed 
initially to include a count field for products and rates, the first iteration will allow for one product, 
one rate. Future iterations will allow for rate changes. In order to support vehicle exchange, clients 
will be allowed to specify multiple car classes. Additionally, all the charges will be allocated to the 
renter. This ability to use multiple groupings for rate specification will be used when Weekend 
special products are used. This allows the charge engine to process the pre-special and post-special 
periods as required by ERAC. 

2.1.3 Database Table Impacts 

VRS includes a comprehensive set of routines for calculating refuel charges. Those routines need 
access to certain tables that will not be used in the ECARS 2.0 implementation. Vehicle unit 
information will not be available until next year and hence price and units for fuel will be passed to 
jjjthe charge engine from the GUI. Additionally, the charge engine uses a set of reference tables for 
^obtaining appropriate charge types when creating a line item. As charge types represent a 
^fundamental piece of a charge item, those tables must be populated with the appropriate information 
J«J- section 3.0 shows a representative set of data. 

HJ2.1.4 DDL Changes 

hi 

f Each charge type is defined in VRS via two database tables: 

pi 

jjj • RRAJ3HGTYPS Define valid charge types 

j| • RNT_AGR_CHG_CATS Define categories of charges 

P 

pin addition to the above tables, the charge engine uses RNT_AGRj:HGJJNITJTYPS table to pick 
up a code used in creating auxiliary keys for each line item created. The charge engine will continue 
to generate the auxiliary keys although they will not be included as part of the data passed back to 
the client application. 

2.1.4.1 RRACHGTYPS 

This table defines all the valid charge types within VRS. The discountable field is being added to 
satisfy a future requirement for discounts. Discussions are under way between Perot and Enterprise 
to include the definition of a chart of accounts and its relationship to the charge items created by the 
charge engine. It would be possible to conform to an external set of charge type values such as the 
ones used by Peoplesoft by populating the RRAJ3HGJTYPS table with the desired values. 
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RRA CHG TYPS 


Columns 


CHG TYP 

VARCHAR2 (5) 

NOT 

NULL 

CHG DESC 

VARCHAR2 (35) 

NOT 

NULL 

CHGJJSE 

VARCHAR2 (1) 

NOT 

NULL 

COST CNTR TYP 

VARCHAR2 (2) 

NOT 

NULL 

GLT_SEQ 

NUMBER (6) 

NOT 

NULL 

INP_OUTJTX 

VARCHAR2 (1) 

NOT 

NULL 

NET REV USE 

VARCHAR2(1) 

NOT 

NULL 

RCC CHG CAT 

VARCHAR2 ( 3 ) 

NOT 

NULL 

TXBL 

VARCHAR2 (1) 

NOT 

NULL 

DISCOUNTABLE 

VARCHAR2{1) 

NOT 

NULL 

CHG SEQ 

NUMBER (6) 



GROSS_REV_FLG 

VARCHAR2(1) 

DEFAULT T N ' 


h 

isr 

S1J 

ill 

CJ 


Primary Key 
CHGJTYP 

Indexes 


Foreign Keys 

RCT FK (RCC CHG CAT) 


REFERENCES RNT__AGR_CHG_CAT S ( CHG__CAT ) 


[A 


Check Constraints 

VALID_RULE281 ( gross_rev__f Ig IN ( 1 Y 1 , 'N' ) ) 
SYS_C003600 ( chg_use IN ( 1 B r , 1 F 1 , 1 C 1 , f A r , 
SYSJC003601 ( cost_cntr_typ IN ( 'CI' , 'CO* , f VO' 
BA T , f CP T , T CV T , 1 FL 1 , T VH T , ? LO f , 'BO 1 ) ) 
SYS_C003602 ( inp_out_tx IN ( 'I' , ? 0' ) ) 


, »BL' , 


) ) 
T AC 


O 2.1.4,2 RNT AGR CHG CATS 


This table, when joined with the RCTJ3HGJTYPS table, allow categorization of charges. This 
functionality is not required for any of the ECARS 2.0 iterations, but will allow for future 
enhancements when posting the charges. 


RNT_AGR_CHG_CATS 

Columns 
CHG_CAT 
CHG_CAT_DESC 
CHG_SEQ 

Primary Key 
CHG CAT 


VARCHAR2(3) NOT NULL 
VARCHAR2(35) NOT NULL 
NUMBER (6) 


Indexes 
Foreign Keys 
Check Constraints 
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The 'CHG_SEQ' field represents the charge type sequence and the category sequence for RRA_CHG_TYS 
and RNT_AGR_CHG_CATS respectively. The sequence numbers can be used by presentation software to 
order the charges for any customer document or display of the charges. 

RCT_SEQ Charge Type Sequence 
RCCJSEQ Charge Category Sequence 


Below is a representative set of data contained in the tables. 




at . cs&Mp 






RNT 

00001 

TIME & DISTANCE 

Y 

1 

i 


RNT 

00002 

EXTENSION - TIME & DISTANCE 

Y 

3 

l 


RNT 

00003 

UPGRADE - TIME & DISTANCE 

Y 

4 

l 


RNT 

00004 

EXTRA DISTANCE-TIME & DISTANCE 

Y 

7 

i 


DIS 

00005 

DISCOUNT - TIME & DISTANCE 

Y 

1 

2 


INS 

00006 

CDW / LDW 

Y 

1 

4 

3 : 

INS 

00007 

PAI 

Y 

2 

4 


INS 

00008 

THEFT WAIVER 

Y 

3 

4 

!f! 

INS 

00009 

GOODS IN TRANSIT 

Y 

4 

4 

11 


UUU-LU 


y 

5 

4 


INS 

UUU11 

T VTC 1 TTT3 7V Kf/T TTVT'TCC 

v 

c. 

4 


SPE 

00012 

RENT - SPECIAL EQUIPMEN1 

v 
I 

J. 

K 
*J 


SPE 

00013 

REPLACE - SPECIAL EQUIPMENT 

Y 

2 



CDR 

0OO14 

COMMUNICATION DEVICE RENTAL 

Y 

1 

24 


CDR 

00015 

COMMUNICATION DEVICE REPLACEMENT 

Y 

2 

24 


CDU 

00016 

COMMUNICATION DEVICE UNITS 

Y 

1 

25 

ga, 

ONW 

00017 

DROP CHARGE 

Y 

1 

O 

IW 

DAC 

00018 

DELIVERY 


1 

/ 


DAC 

00019 

COLLECTION 

Y 

2 

7 

&i 

AFH 

00020 

AFTER HOURS 

Y 

1 

8 

ALW 

00021 

ALLOWANCE 

Y 

1 

9 


FUL 

00022 

REFUELING SERVICE CHARGE 

Y 

1 

12 


SUR 

00024 

AIRPORT SURCHARGES 

Y 

1 

15 1 


SUR 

00025 

OPTIONAL SURCHARGES 

Y 

2 

15 


VAT 

00028 

VALUE ADDED TAX 

N 

5 

17 


RNT 

00029 

UNLIMITED DISTANCE-TIME & DISTANCE 

Y 

8 

1 


LDF 

00030 

LOCATION DIFFERENTIAL 

Y 

1 

3 


INS 

00031 

PERSONNEL EFFECTS COVERAGE 

Y 

8 

4 


INS 

00032 

SUPPLEMENTARY LIABILITY INSURANCE 

Y 

9 

4 


INS 

00033 

PEACE OF MIND 

Y 

10 

4 


QSP 

00034 

QUALITY SERVICE PROGRAM* 

Y 

1 

10 


FUL 

00035 

FUEL SERVICE OPTION 

Y 

2 

12 


YRT 

00036 

YOUNG RENTER FEE 

Y 

1 

13 


ADR 

00037 

ADDITIONAL DRIVER 

Y 

1 

14 


SUR 

00038 

CONTRACT MANDATED SURCHARGE 

Y 

3 

15 


SUR 

00039 

LEGAL MANDATED SURCHARGE 

Y 

4 

15 


CPN 

00044 

DOLLARS - COUPON* 

N 

1 

18 


CPN 

00045 

FREE DAY - COUPON* 

N 

2 

18 


CPB 

00046 

BUSINESS ACCT - COUPON 

N 

1 

19 


CPD 

00047 

DRIVER - COUPON 

N 

1 

20 


RNT 

00048 

FREE DISTANCE - TIME & DISTANCE 

Y 

5 

1 


VAT 

00050 

STATE TAX 

N 

1 

17 


MIS 

00051 

MISCELLANEOUS 

Y 

1 

11 
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H%:tlM^L#| 



RNT 

00052 

EXTRA - TIME & DISTANCE 

Y 

2 

i 



VAi 

r\ n c o 

COUNTY TAX 

M 
IN 


1 *7 
± / 



ruN I 

U U U J - 

CjAXiVH £ rUliHi UXO iiilNL,]ii~ 1 XiXLcj uiolANut) 

Y 


1 
J- 



\77\T 

UUUjj 

PTTY HPftY 

N 


17 



Vri 1 

UUUjD 


N 

4 

17 




UUUj / 

£ VJi\£ EjX ICjU ViiijUiii ~ UUUirUIN 

N 

3 

18 



o Vri 

UUUoU 

rVV DKiVHiK bXtLbo — UVK 1NV 

y 

X 

X 



O V X 

UUUOX 

£VV DKxv&K fiiALLob - VCn XiW 

y 

X 

X 

00 



VA1 

UUUoo 

INSURANCE TAX 


o 

1 7 
x / 



INS 

UUUoo 

STAND LIABLE 

v 

/ 

A 




orb 

uuub / 

BOOSTER SEAT - SPECIAL EQUIPMENT 

Y 

n 

X 




C Tit? 

SPE 

UUCJ6a 

CHILD SEAT — SPECIAL EQUIPMENT 

Y 

X 

i 

X 

c; 

-j 



oFb 

uuuoy 

T1>lTT , 7\ "Kirn O tT 1 7\ T> OTTPOTUT D^iTTT l"VH/f TT'TTTm 

xJNiiANi b&Ax - brrjUiALi EyUIPMENT 

Y 

X 

1 

X 

•J 



SPE 

00070 

LUGGAGE RACK - SPECIAL EOUIPMENT 

Y 

1 

5 



SPE 

00071 

CELL PHONE - SPECIAL EQUIPMENT 

Y 

1 

5 



SPE 

00072 

SKI RACK - SPECIAL EQUIPMENT 

Y 

1 

5 



SPE 

00073 

TIRE CHAINS - SPECIAL EQUIPMENT 

Y 

1 

5 


is 

^RNT 

00000 

PKG BASE DURATION 

Y 

1 

1 


f 

JCPN 

00077 

DOLLAR - COUPON 

N 

4 

18 



tCPN 

00078 

FREE DAY - COUPON 

N 

5 

18 



iCPN 

00079 

FORFEITED VALUE - COUPON 

N 

6 

18 



m 


ill 
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3.1 Charge Engine 


The Charge Engine obtains most of the information it needs from the input parameters. Many of the 
input parameters, if not populated, will cause the Charge Engine to produce a "partial" list of 
charges. That is, if all of the required input arguments are not populated prior to calling the Charge 
Engine, the charges that get created will be a subset of the charges that could be created for that 
rental agreement. All input arguments are copied into a structure and passed to the tuxedo service 
module for processing. All internal charge creation routines (ropuOxxx) take its input arguments 
directly from this structure. The interface to the charge engine is defined in BILENGTFOO Infields 
and BILENGTV001_views. 

Inputs 

Note: 

L The attribute 'excjnileagejrate' will be implemented as a single rate for all rate buckets. 
An issue is added at the end of the document for later resolution as to whether there is an 
Enterprise requirement for individual specification for each rate bucket (hourly, daily, 
weekly and monthly). 

2. Grayed-out rows will not be used for Iteration 2 and 3. 

3 . For all groupings of charges in the following table, a field is mandatory as noted only 
when the count field ('Number of Records') is greater than 0. 

4. Group the vehicle exchanges independently of vehicle rates. Client application is 
expected to create a rate structure for each vehicle movement. 

?JBSP 














Size 

Standard Header 

The content of this header will 
be used for debugging, user 
test support, performance 
monitoring, tuning and error 
looking 

refer to standard header document for 
layout and population rules 

Mandatory 



All Clients 


View Version String 

identification string for this TUX 
server 

FN_BENG_VIEW_VERS10N 

Optional 

string 

100 

Tux View 

calijnode 

Call Mode - Indicates what 
mode the engine is to execute 
in: RS - Reservation, CO - Pick- 
up, CI - Return, AR - Amend 
Rental, Al - Amend Invoice 

FN_BENG_CALLMODE 

Mandatory 

string 

3 

Client App 

rental_type 

Replacement rental. Domain 
values: T, 'D', 'B', «F 

FN_BENG_TRANSACTION_TYPE 

Optional 

char 

1 

Client App 

res date 

Reservation date 

FN BENG RES DATE 

Optional 

string 

13 

Client App 

co date 

Pick-up Date 

FN BENG CO DATE 

Mandatory 

string 

13 

Client App 

co_cry 

Pick-up Country 

FN_BENG_CO_CRY 

Mandatory 

string 

3 

Client App 


3.1.1 


in 

!» 


5i 

if. 
ill 

II! 
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co curr 


Pick-up Currency Code 


FN BENG CO CURR 


Optional 


mat 


string 


Client App 


co stn id 


Pick-up Station ID (Branch) 


FN BENG CO STN ID 


Mandatory 


string 


11 


Client App 


co cornier id 


ra/ ravf. rox or, 3 


F N ' 3E^C CO CCU'NTErf ^ 


co state cd 


State code (ie. FL) for CO 
station 


FN_BENG_CO_STATE_CD 


Mandatory 


string 


Client App 


ci date 


Return Date 


FN BENG CI DATE 


Mandatory 


string 


Client App 


ci curr 


Return Currency Code 
(required for fuel charge) 


FN_BENG_Cl_CURR 


Optional 


string 


Client App 


ci stn id 


Return Station Id 


FN BENG CI STN ID 


Mandatory 


string 


Client App 


Recalc_unit_flag 


When set to 'NT, CEwili 
charge units as received. 
Default is 'Y' - recalculate 
and optimize 


FN_BENG_RECALC_UNIT_FLAG 


Optional 


char 


Client App 


billing_cycle 


, C , =Calendar,'H , =24-Hour- It's 
a mandatory parameter rf the 
recalc flag is set to V 


FN_BENG_BILLING_CYCLE 


Optional 


char 


Client App 


j 8 grace_period 


Grace period in minutes 


FN BENG GRACE PERIOD 


Optional 


long 


Client App 


•«~ earliest co dow 


Earliest day of the week for 
Pickup 


FN_BENG_EARLlESTCO_DOW 


Optional 


long 


Rate Engine 


Is iatest_cijdow 


Latest day of week for return 


FNJENG„LATEST,CLDOW 


Optional 


long 


Rate Engine 


H rental_duration 


i; 

its 


Total Rental Duration in Days. 


FN BENG RENTAL DURATION 


Optional 


long 


Rate Engine 


foucherjJsys 


to< package rates this fsela 
lod:ca?3S the number of aays 
coveiea "ho voucher ( nor- 
zexo V PKG) 


BENG VOUCHER DAYS 


Option*?! 


lone 


K f , 


! 5 pon_jd 


;on:rsct ic 


FN BENG CON ID 


Options 


A 


kept Ap?> 


incljlag 


Tax Inclusive Flag 


FN BENG INCL FLAG 


Optional 


char 


Rate Engine 


srchgjncljlag 


Surcharge Inclusive Flag 


FN BENG SRCHG INCL FLAG 


Optional 


char 


Rate Engine 


r tax_exempt_flag 


Tax Exemption flag 


FN BENG TAX EXEMPT FLAG 


Optional 


char 


Client App 


kip_code 


Zip Code of Renter - Required 
for SOME local surcharge 
exemptions 


FN_BENG_ZIP_CODE 


Optional 


long 


Client App 


wa»ve_arpr_fee 


fY)*Dorrt charge aircoi 
co^oess on fee 


FN BENG WAfVF ARP1 *~EF 


Optional 


Rate F.*wp 


3#aikingjag 


Pass-trreugh $ag to? surcharge 


FN BENG WALKING FLAG 


Optional 


char 


engine 


Client App 


psLtoJoaJteg 


Y-PST lax is prepaid. N 


FN SENG PST TO BA FIG 


Optional 


cha: 


asc to Da rlaq 


FN BENG GST TO SA FIG 


dfop_chgs_to_c5_flg 


v =Drop entrees a*e urep3*o. M 
otnsrwse 


Ktf_BENGJDRO*_CHGS TO BAJ-X 
G 


Opuons* 


shar 


MA 


one_way_tariff 


One way tariff / Drop charges 
flat amount 


FN_BENG_0NEJA/AY_TAR1FF 


Optional 


double 


Rate Engine 
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num_vhci 


sftslgss' 


4 : 


Calc_mode[1 0] 


Gasoline Calculation Method: 

- '8 - -Liala L^sed on 

- ca*cu>ie based on 

V - calculate using rflg_qty 
& rflg_cost 


FNJ3ENG_CALCJv10DE 


Optional 


char 


Client App 


Vhcl_uniLnbr[10j 


Vehicle Unit Number 


FN_BENG_VHCLJJ NIT_N BR 


Optional 


long 


Client App 


VhcLclass[10] 


Vehicle Class Code 


FN BENG VHCL CLASS 


Optional 


string 


Client App 


VhcLclass_sfx[10] 


Vehicle Class Suffix 


FN_BENG_VHCL_CLASS_SFX 


Optional 


string 


VhcLown_state[10] 


State of Vehicle Registration 


FNJBENG_VHCL_OWN_STATE 


Optional 


string 


Client App 
Client App 


VhcLmake[10] 


Make of the vehicle 


FN.BENGJVHCLMAKE 


Optional 


string 


Client App 


VhcLmodel[10] 


Model of the vehicle 


FN BENG VHCL MODEL 


Optional 


string 


16 


Client App 


Vhci_wt[10] 


Vehicle Weight in tons 


FN BENG VHCL WEIGHT 


Optional 


double 


Client App 


Vhcl_price[10] 


Vehicle Price 


FN_BENG_VHCL_PRICE 


Optional 


double 


TotaLannuaLVLF[10] 


Annual Vehicle License Fee 


FN_BENG_ANNUALVLF_FEE 


Optional 


double 


8 


Client App 


Client App 


accumulated _VLF[1 0] 


Accumulated Vehicle License 
Fee (Up-to-date) 


FN BEMG ACC VLF FEE 


Optional 


double 


Client App 


Vhcl_reg_exp_dt[10] 


Vehicle Registration Expiration 
date 


FN_BENG_REG_EXP_DT 


Optional 


string 


Client App 


VhcLtype[10] 


Vehicle Type, CR=Car, 
TR=Truck 


FN BENG VHCL TYPE 


Optional 


string 


Client App 


VhcLreg_cry[1Q] 


Vehicle Registration Country 


FN BENG REG CRY 


Optional 


string 


Client App 


S5= 


co_odmtr[10] 


Check Out Odometer 


FN_BENG_CO_ODMTR 


Optional 


long 


Client App 


3 n: 


ci_odmtr[10] 


Check In Odometer 


FN_BENG_CLODMTR 


Optional 


long 


Client App 


i'gli 

hi 


Tank,est[iOj 


Tank Estimste (on rei.m) In 


FN SENG TANK EST 


Optional 


4 


N/A 


FueijMrtfi Oj 


Tank Esthete (on pfcfttw) ir- 


FN BEMG FUEL OUT 


k>no 


h'A 


rflg_qty[10] 


Refuel Quantity 


FN BENG RFLG QTY 


Optional 


long 


Client App 


rflg„cost[10] 


Refuel Cost 


FN BENG RFLG COST 


Optional 


double 8 


Fuelj>rcjypr*01 


VRS Hc7 r ueHna Price Tvpe 


FN BENS FUEL PRC TYP 


Optional 


Client App 



refuel coder "*G] 


Cent* act Fixe* Gpron refuel 
coo* 


FN BEHG REFUEL CODE 


Op-Jons! 


ainna 


re&eljype[10; 


FN.SENG^REFUELJfYPfc 


Optional 


fueljncl[10] 


Fuel is included in rates, usually 
in PKG products 


FN BENG FUEL INCL 


Optional 


char 


Rate Engine 


fuel_unbld_rent_rt[1 0] 


The amount for full tank of gas 
to back out of the T&M rate 


FN_BENGJ r UEL_UNBLDRENT_RT 


Optional 


double 


Rate Engine 


vhcljcchg_dt 


Vehicle Exchange Date 


FNBENG_VHCL_XCHGJ)T 


Optional 


string 


13 


Client App 
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B^land Mileage, 


num_rate 

One record Der Droduct oer 
rated to 10) 

FN BENG HUM RATE 

victiiudLUi y 


2 — r 

ouent r\pp 

ratejype[10] 

T)ime & Mileaqe. Vlariable 
Rate, or P)ackage 

FN BENG RATE TYPE 


wt iCtl 

1 

Ra+A F nn in p 

prod_insLcd[10] 

Product instance code 

FN BENG PROD INST ID CD 

Wlandatorv 

sfrina 

Oil M IU 

Q 

c 

Rat^ Fnninp 

pin. ver. mn .01 

Proauct vsr ?fcn ~i-nu3 r 






excjnileage jate[1 0] 

Per Mils rate for milp^ in pynAce 
of total allowed free miles 

FN RFNlfi FXP Mil PAf5P RT 


(JUUDIc 

O 
O 

rcaie engine 

: vhcljd[10] 

OCJHIC do VCItllriC Ul lll HUillUC?! . 

' ' 'I ■ . ' 

- - ■ 

. - ~ ; 




eff_start_dt[10] 

OlCtlVliiy UaLC/tlltlC 1UI LI Mo Idle 

instance 

cm RFKIrt RATF <iTRT 

ivtanQaiory 

siring 

JO 

uiient App 

efLend_dt[10] 

Fnrlinn Hafaa frtrthic rata 
t-JIUtfty Udlc lUt Ullb laic 

instance 

FN RFNf5 RATF FWH 

ivianaaiory 

siring 

10 

uiient App 

?; tmjiours[10] 

basic Kentai iNumoer ot nours 
hourly rate 

CM D CMA Tfcil 1_1/*M IQO 

rN_BbNG_Tlvl_nOU Ko 

Optional 

ong 

4 

Rate Engine 

I tm_hourlyj*ate[1 0] 

basic Kentai Hourly rate tor 
hourly charges 

rN_BENG — TM_HOURLY_RT 

Optional 

double 

8 

Rate Engine 

* tm_hourly_miles[10] 

Basic Rental Number of free 
hour at hourly rate 

FN_BENG_TM_HOURLY_MILES 

Optional 

long 

4 

Rate Engine 

| tm_days[10] 

Basic Rental Number of days 
daily rate 

FN_BENGJTM_DAYS 

Optional 

ong 

4 

Rate Engine 

f tm_daiiy_rate[1 0] 

3 

Basic Rental Daily rate for daily 
charges 

FN_BENG_TM_DA1LY_RT 

Optional 

double 

8 

Rate Engine 

tm_dailyjniles[10] 

Basic Rental Number of free 
day at daily rate 

FN_BENG_TM_DAILY_MILES 

Optional 

long 

4 

Rate Engine 

[ tm_weeks[10] 

5 

Basic Rental Number of weeks 
weekly rate 

FN_BENG_TM_WEEKS 

Optional 

long 

4 

Rate Engine 

| tm_weekly_rate[10] 

i 

Basic Rental Weekly rate for 
weekly charges 

FN_BENG_TMJA/EEKLY_RT 

Optional 

double 

8 

Rate Engine 

* tm_weekly_miles[10] 

Basic Rental Number of free 
week at weekly rate 

FN_BENG_TM_WEEKLY_MILES 

Optional 

long 

4 

Rate Engine 

. tm_months[10] 

Basic Rental Number of months 
monthly rate 

FN_BENG_™_MONTHS 

Optional 

long 

4 

Rate Engine 

tmjTionthly_rate[1 0] 

Basic Rental Monthly rate for 
monthly charges 

FN_BENGJTM_MONTHLY_RT 

Optional 

double 

8 

Rate Engine 

tm_monthly__miles[1 0] 

Basic Rental Number of free 
month at monthly rate 

FN_BENG j™_MONTHLY_MI LES 

Optional 

long 

4 

Rate Engine 

tm_extra_days[10] 

Basic Rental Number of "extra" 
days charged 

FN_BE N G_TM_EXTRA_DAYS 

Optional 

long 

4 

Rate Engine 

tm_extra_dayj-ate[1 0] 

Basic Rental Per day rate for 
"extra" days 

FN_BENG_TM__EXTRA_DAY_RT 

Optional 

double 

8 

Rate Engine 

tm_extra_day_miles[1 0] 

Basic Rental Number of free 
day at extra_day rate 

FN_BENG_TWl_EXTRA_DAY_MILES 

Optional 

long 

4 

Rate Engine 

tm_extra_hours[10] 

Basic Rental Number of "extra" 
hours charged 

FN_BENG_TM_EXTRA_HOURS 

Optional 

long 

4 

Rate Engine 

tm_extra_hourjate[1 0] 

Basic Rental Per hour rate for 
"extra" hours 

FN_BENG_TM_EXTRA_HOUR_RT 

Optional 

double 

8 

Rate Engine 

tm_extra_hour__miles[1 0] 

Basic Rental Number of free 
hour at extra hourl rate 

FN BENG TM EXTRA HOUR MILE 
S 

Optional 

long 

4 

Rate Engine 



var_sunj*ioii$[10] V£R Cents' fcumbe< o* 

Su^ds^ hours 




4 
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Input Partwei&W^Sitr 






war sunjioui.;.. :-?e -«;. 


•N. Bt-NG VAR_ 3US>0:JRLV_F r 





var_moii_hou; 5= \ Oj 

vAR ReT.*u. Ris^ia; c s 

F^^G„\ AR.MON .HOURS 

Cp*!Oiis! 

on q 



var_monJioupy_ rsu^e; 

v'AF. R=uai hci;?iy raw fc* 

F^„ B£HG_VAR^ON_HOCPLY_RT 

Optionai 


5 

Rn;e d'V^ f - 


VAR Rente: *\i?noe. or 

F^8£NG^AR^-UE^HOUR3 

Dvionai 

one 

.d 

Ra^e Engu-ic 

var^tusjioudy /ate./0| 

V>._R Ronr?« HctifiV rely ib" 

fU ^ B£NG J^AR_jT*J£_HOUR L Y _RT 

Opuo'ia! 

ooi-cie 

S5 



VAR Rente. KunMra oi 
Vvs*inef do' / hours 

FN^BENGJ/ARJWED^HOUKS 


on 3 

4 

Ra«f Ermine 

vafjwedjioudy^rstej *0| 

VAR Rmta, Heu% f&ie for 

FH_BEhlGJV^RjA/SD_HOURLY_.RT 

Opticnal 

do..bie 

8 

RatC Engine 

varjhu_hour*(iO] 

VAR Rentsi Ntrroe- o- 

PN,6£NGJ/ARJTHU_r!OuRS 

Ooucnal 


4 

R.V,e E»i9in? 

varJhojiouriy^/afei'iO] 

VAR Rente. H<*iriy rate for 

r h _BE NG_VAR_T H\J_Jl Gl ;RLV_R f 


doyble 

b ■ 

Rata Engine 

i vsrjryioufs[l0] 

VAR Rema. N-jraer of f r.aay 

r N_BENGJ/AR_FRLHOUR3 

0«nonft! 

long 


Rate br>glne 

P V8r_frijjourlyj^^e[10] 

VAR Rente. Hourly ;a*s 
riiciay nous *y cnaicjes 

c N_BENOJVAR_FR;_hOURLY_RT 

Qpironal 

double 

0 

R<^te Engirt® 


VAR Rental Nunra- c> £ 
SHiurcJay nouis 

FN_BENG_VAR_SAT „ HOURS 


lone 




VAR Rents' Hourly role fur 
o3.iii!u^v rt ouny c iai^s 

FN^SENG JvAR^SA F_HOuRLY_R T 

Opucnal 

OOUDtO 

8 

Rate E'cins 

| var_sun_days L 0] 

VAR Rent©- Wurr.oar c>: 
oo^ciay oavs» 

FM_BENG_VAR_SUN_DAYS 



4 



VAR Rental Daay rate fo<" 
SurCay Dsitv charges 

FM„ScNG„VAR_SU^DAILV_RT 

Optional 


p 

Ratss E'igsne 

■ 
I 

VAR Rents' Hurw of 
i«iO' sg&y 3*iy5? 

r^BENG_VAR_MON_OAYS 

Opt ion a! 

scng 

4 

Rate Enguie 

f varj^on^ dai ; y_r se> 1 0] 

VAR Reni^ Daily ^ fo«- 

FH_BB HO yARJJlOH^DAl LYjRT 

Options! 

doL-bls 

3 

Ra'c Engine 

j varjue_daysf10i 

VAR Rsnta 1 Number of 
J i«ftsn3y days 

FN_B£NG„VAR_TUE_DAYS 

Optional 

long 

4 

Rare Engine 

vsrjue_d any... "-step 0; 

VAR Renta' Daily rg^e tcr 
i ijtfSuav uai*v cnsr^sfs 

FN_SE NG_}JA RJTUEJjAILYJRT 

Optional 

double 

8 

Raie Engine 

var_wed_days[ ! Oj 

VAR Rente. Nance) o< 
VVsdnssday days 

FN^EENG J/AR JWEOJDAYS 

Optional 

'ong 


Raie E'igine 


VAR Re^ta Daily rate frv 
VVadneedav Da'ly oh3;ca» 

FN _8ENG_VAR_V\/E0_DA! LY_RT 

Optional 


S 

Ra-e Engine 

var^thujlays'/'Ol 

Tivj'Sdsy a»ys 

FN_8ENG_VAR_1 HU_ DAYS 

Options! 

lone 

4 

Rata E:^na 


VAR Penlai Ca?i/ rate for 
Thursday Danv chafes 


Opuonai 


3 

Rate c"Qirt© 





V,nc 

4 

Rale R'"Qin& 


VAR R^nla« Daily raia fo. 
Srida^ Ca"y cHaross 

FM_8 E h G_ VA R_F R !_DA I L Y_RT 

Ootbnai 


" 

Raie Eng^e 

var_sal_dayivf ' 

VAR RenU Mimire- o' 
$:.T.u'vay :.uys 

FN.3EK-3„VAR„SAT^0AY3 


lor?:< 

4 

f^'s E-ome 


VAR Rent* Daily r?i6 fc^ 

FN„SENG„VAR„SAT_D^lY..RT 

Op'W^ai 




varjweeKsf'i^i 

VAR R^ru^: . Vr\„^* A'^tko 

Fm DENG VAR V/EEiKS 





var_week;-y_ ^ 

VAR Rent^ vea^v ,s:fefw 

FN_3EN<3_VAFLWEE ! CY 




Rutsa E.:gn:^ 



- K._£cMG_ VAR V:O^Th 3 



4 
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\, He Li*. ^<:~-y rr:a : 0; 


Or.lcr.ai 



i'j en:*? 


^iCT^y Of "es no.r hoiuly 





'\ e z^ro 


Numbsi of ves us/ at ca^ 
•rt 




& 


vsrjweaklyji- ;a$: 'i 5 : 

:\*i:,**ds* of nee ^'eefc rt 
wssfdy rata 



olc. 

<? 



Mumbe~ nee mom^ at 
rooirhiy 'ale 


0f/jcn3! 

ClOVOb 









c 


PKG base duiaiiopnOl 

l^nuiKpr of n^y^ of hp™* 3 
pa ckage d u ration 



5 'i? 

i 5 1 









P£<£2 ,avTrffl hnnr rA'-^MO" 




ULn - 

o 


PKG„6xtra.„days[10; 

Numoer cr Extra Days used 
sfle< ms Pius Dave 

FN.BENG^PKG.EXTFW .OAYS 

Optlci^a? 

long 


Rste E'sgltifi 

PKG_ejdra_day. 'afenoj 

Exta Day Rate 

FN BFKG PKG EXTRA DAY RT 

OpUQftZl 



Rate- EA^hie 

PKG_extra vrae^sfiOl 

Miimber of Extra VvseKs ussd 

FN BENG PKG EXTFlA WEEKS 


Jones 


RatoF^&lns 

PKG... extra... **'&e^ -ass^O? 

Exlrs W«sk Hc-ls^ 

FN D£HG PKG EXTRA WEEK RT 

Optional 


8 

<%h:g E"ome 

PKG Jreejn lies* 1 CC 

Fre^ Mi.es fortne Voucher 


Optional 

long 

4 

Pale E^ome- 

PKG_upgracej a^[': 0] 

U-pgrace R3i€ fc» the PacKage 
Duration 

f H_8£NG_PKG JjPGRADE_R7 


double 

8 

^aie Engine 

PKG_extenJu>u'S[lO] 

Mumber of hours oackage 
e>?tons-on 

FN_BENG_PKG_EXTM . HOURS 


tag 

4 

Rare Engine 

PKG.exten houcrarejic: 

Hourfy 'at* for package 
extensions 

FN^ BEHG_PKG_EXTN_HCUR_RT 

Optional 


<*> 
c> 

Rate Enoine 


Number of cays or package 
extension 

FN. B£NG_FK G_£X TH_ DAYS 


long 

4 

Ra:e Engine 

PKG_exfcen_ day jate{1 0] 

dasly rate for oad^age 

FN BENG FKG EXTN DAV RT 

Optional 


>j 

Ra:e Engine 

FKG exten weekaftC' 

? w^eks psckaos extension 

FN BENG PKG EXTN Wfc£KS 

Opaonai 

(0*10 

4 

R«:e E^ojne 

PKG_erten jscekjateC I Dj 

^ekfy rata fo* pac^'age 
exisnsion 


Opiivnai 


8 

Re« Eigir.a 

FKG extern free ~-<3s r i01 

r rea rv { ::a? c or jhe? Extension 

FN BENG FKG tXTH FH?-:E MILES 


lor.q 

4. 

Rats E-Qjna 

PKG>8.ho«ry>iSes[10I 

res hourly package rules 

F^SE^G_PKG„FREEJ^OURLYJ^!L 
— - 



4 

Rate Engme 

PKGJree daily _mHesf *G*T 

free dan'y package nves 

FN BEMG FKG FREF DAI*„Y ^!LES 

Opticnal 

lonr 



PKG Jrsa_waeklv„mtles: 1 Gl 

free ^/eekiy pac'iace ^?;es 

FN BENG PKG FREE WEEKLY IvUL 
FS 

Optional 

long 

4 

Rate E^gme 


num_equip 

Number of EQP records to 
process (0 to 16) 

FN J3ENG JvJ UM_SPC_EQ JTEMS 

Optional 

long 

4 

EQP Engine 

Equipment ID[16] 

Equipment Identifier 

FN_BENG_EQP_SPCL_EQPJD 

Mandatory 

string 

4 

EQP Engine 

Item Qty[16] 

Number of Equipment 

FN_BENG_EQP_SPCL_EQP_QTY 

Mandatory 

long 

4 

EQP Engine 

Equipment Description[16] 

Line Item Description 

FN_BENG_EQP_SPCL_EQP_DESC 

Optional 

string 

36 

EQP Engine 

Comm. Device F l ngf -0: 

ComraurPcaBC";S Dev ce Flag 

FN_3ENG_EQP_COMWLDVC^FLG 


char 


EOF Engjne 

Rental Charge Type[16] 

Assigned Charge Type 

FN_BENG_EQP_RCT_CHG_TYP 

Mandatory 

string 

6 

EQP Engine 

Rental Amount[1 6] 

Per rental amount 

FN_BENG_EQP_SPCL_EQP_RT 

Optional 

double 

8 

EQP Engine 

Rental Count[16] 

Per rental unit (always equal 

to 1) 

FN_BENG_EQP_SPCL_EQP_CNT 

Optional 

long 

4 

EQP Engine 

Replacement Amt[l 6] 

Replacement amount for lost 
equipment 

FN^BENG^EQP^REPL^AMT 

Optional 

double 

8 

EQP Engine 
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■Sue] 



Replacement fiag[1 6] 

if Y create active line for 
replace amount 

FN_BENG_EQP_CHGS_REPL_FLAG 

Optional 

char 

1 

Client App 

Hourly Rental Amount[16] 

Hourly rate 

FN_BENG_EQP_S PCL_EQP_HR_RT 

Optional 

double 

8 

EQP Engine 

Hourlv Countfl 61 

Nlumhpr nf HfMirs 

PM RPW<^ PHD CD^I CAD UAHDC 

vjptionai 

long 

4 

EQP Engjne 

nailv Rental Amrmntnfil 

UcLliy rxeUG 

CM DCMP CAD ODPI rAn nv DT 

r N_D_No_bQH_oPGL_EQP_DY_ KT 

Optional 

double 

8 

EQP Engine 

Daily Count[16] 

Number of days 

FN_BENG_EQP_SPCL_EQP_DAYS 

Optional 

long 

4 

EQP Engine 

Weekly Rental Amount[16] 

Weekly rate 

FN_BENG_EQP_SPCL_EQP_WK_RT 

Optional 

double 

8 

EQP Engine 

Weekly Count[16] 

Number of weeks 

FN_BENG_EQP_SPCL_EQP_WEEKS 

Optional 

long 

4 

EQP Engine 

Monthly Rental Amount[16] 

Monthly rate 

FN_BENGJEQP_SPCL_EQP_MO_RT 

Optional 

double 

8 

EQP Engine 

Monthly Count[16] 

Number of months 

FN BENG EQP SPCL EQP MONTH 
S 

Optional 

long 

4 

EQP Engine 

Max Rental Amount[16] 

Maximum EQP charge for the 
rental 

FN_BENG_EQP_.MAX_RNT.AMT 

Optional 

double 

8 

EQP Engine 

Inclusive Flag[1 6] 

Indicates that value is bundled 
in T&M rate 

FN_BENGJEQP_SPCL_EQP_1NCL 

Optional 

char 

1 

EQP Engine 

; Participation Flag[16] 

Can be charged 

FN_BENG_EQP_SPCL_EQP_PART 

Optional 

char 

1 

EQP Engine 

i Unbundled Amount[1 6] 

Daily amount for included 
Equipment 

FN_BENG_EQP_UNBLD_DY_RT 

Optional 

double 

8 

EQP Engine 

; Equipment Start Date[16] 

Start date for equipment 

FN_BENG_EQP_ST_DT 

Mandatory 

string 

13 

Client App 

; Equipment End Date[16] 

End date for equipment 

FN_BENG_EQP_END_DT 

Mandatory 

string 

13 

Client App 

1 


fve?v in C. :arge u^itlype 

r NJBENGJXLjJN i TJT^PEJN 

Clonal 

St 

4 

Oe>Co\ 
E^-g *ie 

cteLnbr_units 

Penary Cnarge Unite - 
Required if there & to be a 
dsHYsry charge 


Optional 

long 

4 

Oe:Coi 

del_cornb_flag 

De«\'e^ Coinoinaiion F>ag - 
Required if there Is to be a 
deliver/ charge 

FN - b=NG_Dei._COPdiB_F_AG 

Optional 

char 


De s Col 
Eng'ne 

dalJfree_disUp 

DeJ.vsry in see U^tis - 
Reau*r~€l if there Is co ce o 
delivery change a"£ 

PN_BENG_DEi._FREE_.DI3T JH 

Opaonal 


4 

De Coi 

de_fixed_arnMn 

Del vary In Fixed Amount - 
Reaiiireci «T t^e^e Is to be a 
desve? y charge ?rsd 

FN„BEhG_DcL_,RXfcD_AWrrjN 

Optional 


3 

DcCos 
Eng. re 

6e\Jnd_uniysJn 

De^very in induced Units - 
Required if there s$ to a 
celery charge and 
del comb feus = 5 Y\ 

PN_B£KG_D=LJNCL.UN1TSJN 

Oprbnal 

long 


D?Col 

deLa&l _amt_, r 

Oe'ivary In Additions! Charge 
Sals - Recmired i >here is to 
be a cie' very charge «*x; 
del corf»b vao = " fM 

F N_B£ MG_DE L_AODL_AMTJ N 

Op^onal 

oo'Me 

8 

De'Col 
Engine 


De-vers Qui F-eeUnris- 
Re^sren f ;r5iJ* is u> oe 5 

FN^SENG _DE L _F H E E . DISTQLT 

Opi&na! 



Eng r.e 


DS'iVA, C;u Free; Arru v ? - 
!Reeu?f?d i Jiora ;s to ce a 

ce' cvtsifc - C" 




S 

De Co* 
Er.c: "c 


DeHe-> 0<u Cna>r& unH Type 
- 7?a>z'J:£a 'f ;h~ve s 'c oe 
aeuvery ch^gc a "3 
as! cer^b ;:ap - C* . 

M^BSNG - DEL^:n'„Tvpc v OLr 



■4 

Oe;0o: 


Last Save Date: 1 1/5/2001 10:22 AM 


Page 18 of 51 


Charge Engine Detail DesignJS 


t53T\ 



bm< rent-a-car 


ECARS v2.0 - Accurate Out the Door Pricing 
Detailed Design Specification 


perotsystems 




BWBE3SjffHSTMl 


bbbbs 





?U < fC IS ? TO vV 5? 

d&Kver;- chare;- s..c! 
✓ei c<-^b fv? = '0 . 


'^pJCi.oi 


4 

C^*cr ^ 0 ; 

deljaddijamtjj'ji 

De Out Addtona 

Hers is »c oc 2 de!u-e y crcrge 
a d oaf. co^sa. j*sg - "0". 


Opjcnai 



ring ~e 

coy=brjjnvte 

Secv* cd r i!ie<e ;s *c ce s 
collector, c^arqe 


Optional 

Lr»o 

.1 

De Coi 


Co? eclion Comb^siio" Hag - 
Reared >f ^here js to oe a " 
collect-on c^aroe 

FN_B£NG_C0L_C0?4B_FLAG 

Opjonei 

Chr^ 


De'Col 


GoMaao^ »n F^.b Units - 
Required t ifa.e 5 s to oe a 
coitecfcon charge ami 
co! comb fiac, - *' 





De:Co« 


CoHaci on r Fsxecs Arcourr - 
Rsquuea if lha<e is fa be a 
collection charge and 
cot ccmb_f!ag = 1 ' 

F <%s _BE NG_CO L__ffXE D AMTJN 

Options! 

douate 

6 

De-Col 
Entire 

coLurotJypejo 

Ootoctson !r Change linU Type 
- r?Qqj»ec if the^e >s :o be a 
cottecllai charge and 
col comb to ~ T 

FM_ShNG_COLJ;>jlT_TVPe JN 

OtAicia! 

striny 

4 

De-Co! 

coljncLumtsjr 

Cc^ecucn m Incused l'rits - 
Required there ts to be a 
collect or; crarge sod 
coi con.b f&q- H 

FN_8ENG_C0LJNCLjJNiTS„iH 

optionsl 

one 

4 

£09 me 

r^Laddl_amt_jn 

Collection inAdd^cna- 
Charge Ra»e - R«eu*fed ,f 
there is to be a collection 
cnarce arcf co^ cenb "ag - 
T. 


OpOonai 


8 

Oe.Col 

coLfre« - .dist i .o,*! 

Coliseum Out Free Units - 
Required :t there is to be a 
cc-Heeticp charge- ar,d 
ecl_eonr.&_ ffcg = C . 

FN_BEN0_COL.FREE_0IST - 0UT 

Optional 

long 

4 

DeCcl 
En^-ne 

■ 

Coiiecfon Ojt Fixed Amount - 
Reautred a" thai© is to ce a 
collet ;cn e % ar&e and 
co- conb. _%c ~ '0 ' 

FHjENG_COU.F!XED_MtT_0U1 

Optional 

docole 

8 

t>) Coi 

co mj n it Jy pe_c in 

Co.»ecLort Ga Charge Una 
Type - Scared c biere ?$ to 
be 3 co-lection change ano 
co! comb Hag - 0 

PN_B6 WG^COL_U N f T_T YPE_ OUT 


string 

4 

De Co; 

ooyncLun«te_out 

Corecton Oct included U~as~ 
Required ; f there \$ to os s 
ccllect'on charge and 
coi comb fbo-'C* 

r*^8£NG w COLJ^CL u^:ts_out 



4 

Uo Co; 
Erg:oe 

GoyiddLamt^rui 

C?; eel cn Oj; Adouooe' 
Gfraijfe c :^te c ^r^m^d ; i 
^>ere ^-c 3 co!tec:;o*i 
cs^rc* s. »'.» c:_cc rvv ^i^j ■= 







Hi 

O 
O 
ill 
Oj 

o 

H 
W 

ill 
PJ 
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numjnsurance 

Number of INS records to 
process (Oto 16) 

FN_BENG_NUMJNSJTEMS 

Optional 

long 

4 

INS Engine 

Excess Deposits 6] 

Deposit Amount, if required 

FN BENG INS EXCS DPST 

Optional 

double 

8 

INS Engine 

Daily Rental Amount{1 6} 

Daily Rate 

FN_BENG_iNS DY RT 

Optional 

double 

8 

INS Engine 

Daily Count[16] 

Number of days 

FN_BENG INS DAYS 

Optional 

long 

4 

INS Engine 

Weekly Rental Amount[163 

Weekly rate 

FN_BENG_INSJ/VK RT 

Optional 

double 

8 

INS Engine 

Weekly Count[16] 

Number of weeks 

FN_BENG_INS_WEEKS 

Optional 

long 

4 

INS Engine 

Monthly Rental Amount[16] 

Monthly rate 

FN_BENG_INS_MO RT 

Optional 

double 

8 

INS Engine 

Monthly Count[16] 

Number of months 

FN_BENG_1NS_M0NTHS 

Optional S 

long 

4 

INS Engine 

RCT Charge Type[16] 

Ins Charge type 

FN_BENG_INS RCT CHG TYP 

Mandatory 

char 

6 

INS Engine 

insurance Type ID[16] 

Insurance Type ID such as PAI 

FNJ3ENGJNSJNS TYP ID 

Mandatory 

char 

9 

INS Engine 

Insurance Description[1 6] 

Textual Description 

FN_BENGJNS INS TYP DESC 

Optional 

char 

36 

INS Enaine 

Applicability Status[1 6] 

I'ncluded, Mandatory, 
'O'ptionai, 'D'o not Offer 

FNJBENG J NS_APPL_STATUS 

Mandatory 

char 

1 

INS Engine 

Unbundled Amount[16] 

Daily amount for included 
Coverage 

FN J3ENG J NS JJNBLD_DY_RT 

Optional 

double 

8 

INS Engine 

, Thresholdjjays 

Number of initial days before 
staggered rates take effect 

FNJ3ENGJNSJTHRESHOLD 

Optional 

long 

4 

INS Engine 

? Nbr_stg_days[16] 

Number of staggered days 

FN_BENG JNSJM BR_STG_DAYS 

Optional 

long 

4 

INS Engine 

! Stg_prm_amt[16] 

Staggered premium amount 

FN_BENGJNS__STG_RT 

Optional 

double 

8 

INS Engine 

| Insurance Start Date[1 6] 

Insurance start date 
(YYYYMMDDHHMI) 

FN_BENGJNS_STJ3T 

Mandatory 

string 

13 

Client App 

I I nsurance End Date[1 6] 

insurance end date 
(YYYYMMDDHHMI) 

FN_BENG J NS_END JDT 

Mandatory 

string 

13 

Client App 


hum_ancly 

Number of Ancillary records to 
process (Oto 16) 

FN_BENG_NUM_CHGJTEMS 

Optional 

long 

4 

Ancillary 

ancly_Jd[16] 

Charge Identifier 

FN_BENG_ANCLY_CHG ID 

Mandatory 

long 

4 

Ancillary 

; ancly_desc[16] 

Charge Description 

FN BENG ANCLY CHG DESC 

Optional 

string 

36 

Ancillary 

! ancly_amt[16] 

Amount to charge for this item 

FN BENG ANCLY CHG AMT 

Mandatory 

double 

8 

Ancillary 


I curr_cd[16] 

Currency code ( USD, CAD, 
etc..) 

FN_BENG_ANCLY_CURR_CD 

Optional 

string 

4 

Ancillary 

! rcLchgJyp[16] 

Charge type 

FN_BENG ANCLY RCT CHG TYP 

Mandatory 

string 

6 

Ancillary 

! chg_unitjyp[16] 

Unit type (D=per 
day,R=rental 1 C=%-based 

FN J3ENG_ANCLY_CHG_UN ITJTYP 

Mandatory 

char 

1 

Ancillary 

ancly_start_dt[16] 

Start date (YYYYMMDDHHMI) 

FN BENG ANCLY START DT 

Mandatory 

string 

13 

Client App 

ancly.end^dtfie] 

End date (YYYYMMDDHHMI) 

FN BENG ANCLY END DT 

Mandatory 

string 

13 

Client App 

chrg drtn[16] 

Duration - required for per day 

FN BENG ANCLY CHRG DRTN 

Optional 

long 

4 

Ancillary 





disc_pcntage 

Discount Percentage if 
applicable or 0 

FN_BENG_DISCPCNTAGE 

Optional 

double 

8 

Rate Engine 


How discount is to oe scprad 

F N_B ENGJDi SC__APPL_5L AG 

Opiiu.iai 

di8! 


Rats oogino 

coupon id's 

Cold in id fcr 1st soupeti 

FN 8£NG COUPON iD? 

OpStcatei 



j Client Apo 

coupon cntl 

Cocoon count for tj st causer 

Fh BENG COUPON C^JT'; 

Optional 

boo; 

4 

Glseot Ado 

co upon Id 2 

Couocn id '?r2od coupon 

FN SENG COUPON !D2 

Optional 

Stnpg 

■i i 

Ch^ n i Aop 


Couoo* co. ni h? 2 5 couoon 

FN B6HG COUPON CN T 2 

Options! 

long 


Cue it App 

coaocn id3 

Co j son la for ore; coupon 

F°H BENG COUPON Oo 


sting 


C1?eot odo 

coupon cnt3 

Coupon .:oun> fcr 3rd col'oci 

FN BENG COUPON CNT3 

Options! 

lOOG 

J 

C&ar,! App 

in>" Hiff r* 

L.ocat on D : ;fe rent* a Rate 

FN SENG LOG DsFF RT 

Ootional 


8 

Rata Eogme 

coup_st_di 

Coupon Start Da;e 
f v Y Y y%i* ?DOHH V- : 

FN_BENG_COU PON_ST_DT 

Optional 

St loo 

13 

Oieot Asm 




Opdoits! 

si- ing 

' 3 

Oer> Asp 
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Is 

y 

31 



Unique identification for the 
renter 

FN_BENG_RENTERJD 

Mandatory 

long 

4 

Client App 

nuro_biijio 

;h s r ^^>cf' v v, £) 



' ' ^ 

* 


billto_icieniiferf8| 

UnlC| Jt** i»3 fo** e*cr t fO 




4 



£»„L-70 





- 5 , rr, 

msx_c!ai!y(8j 

illax^vn Cs;!v a:^^ lor ihi* 






plus_tax_tnd^« 

^6hsv?or f cr *ax charges 



cha; 



■ pius_s rchg_in n . 8j 

B<ih3Vicr for su'eh^ros* 
(;~ rdus ve, E-exo^ive or 
A=actoffive) 





OHO' i ADp 

num_auth_chgs 

Coun? of au: horded crarge 
tynee <*0 to 40* 


Opticas! 

lone 

4 

Ciien* App 

: bHltoJ<Jentif;*v-0] 

Unique ID -crffie BILLTO 

RJ_B!rKG_StLt.' : 0 

OpMona! 


4 


i Ch8fTge_typ?[ji0j 

VRS Charge type (eg *CO0QV = 

FK_SrNG_RCT_CHG_TrT 3 

Qp*JO,15i 

sfnnci 

,a 

Cli^i! App 

1 authcrized.amoun^o'j 

i - - 

Amount BIUL7G \v»» u&sy for thai 
ohasge type 

FN_BE>iG_AUTH_AMOUNT 

Optiona: 


a 



Psfcen: of Charge -ate BILL TO 
w; 1 pav 

FN_B£MG_AU1H_?£SCE?1T 

Opvcnai 



Client App 

1 Charge^freque^q^rjf. 

Frequency at v,-hi,->i au'ncnzed 
amovn* -s eppfrsd 

FN_BEKG_CKARG£_FSEO 

Opitor,al 

CftSf 


C«ier.i App 

auth_slart_mt4Cl 

Authorization start aate 
(yvyYMMDOHHMI) 

!=N_8ENG_AUTH_STAF>v_DT 


string 

13 

Client App 

auth_end_di[4C;] 

Auth enddste 

(yyyymmddhhwo 

FKJBEB6 _AUTK_E»D_OT 

Optional 

stnng 

T3 

Cde^t App 

1 auth_days[4C; 


FH_9-Ne_AvT!^DAYS 

Optional 

icne 


CM^t App 
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3.1.2 Outputs 

The charge engine inserts all charges into the Tuxedo output buffer and returns to the caller. The 
created line items will not be directly recorded into the database by the charge engine. It is the 
calling processes' responsibility to manage the database transaction - the charge engine does no 
commits or rollbacks. The output buffer is defined below. The items under the "FML field name" 
column in BOLD are added to the output for possible future extension. Some of those fields have no 
application at present for this phase of the Enterprise project. 





■ ^''■'Output PJE^0^^r- \ ^i$$$te$e/ 


9H9HBNI 

mm 


error_no 

Server error Code or 0 

FNJBENG_ERR_STATUS 

Mandatory 

long 

4 


err_text 

Server Error Text 

FN_BENG_ERRJv1ESSAGE 

Optional 

string 

81 


sql_errorjio 

DB Error code as applicable 

FNJBENG_SQLJERR_STATUS 

Optional 

long 

4 


sqLerrorJext 

DB Error Text as applicable 

FN_BENG_SQL - ERR_MESSAGE 

Optional 

string 

81 

I/O 

Amount 

Total Estimated Charges 

FN_BENG_AMOUNT 

Mandatory 

double 

8 

r*x/*\ 

uc 

numj;harges (1 - 100) 

Number of line items made up of 
ueiow components 

FN_BENG_CHGS_REC_COUNT 

Mandatory 

long 

4 

CC 

chg_actv[100] 

Activity flag - AS,AN,NS,NN 

FN_BENG_CHG_ACTY 

Mandatory 

string 

3 

cc 

chg_amt[100] 

Line item Charged Amount 

FNJ3ENG_CHG_AMT 

Mandatory 

double 

8 

cc 

chg_basis[100] 

Basis for percent-based charges 

FN_BENG_CHG_BASIS 

Optional 

double 

8 

cc 

chg_rt[100] 

Charge rate 

FN_BENG_CHG_RT 

Mandatory 

double 

8 

cc 

item_qty[100] 

Number of items (See Equipment) 

FN_BENGJTEM_QTY 

Optional 

long 

4 

cc 

chg_unit[1 00] 

Unit Count 

FN_BENG_CHGJJNIT 

Optional 

long 

4 

cc 

In jtem_desc[1 00] 

Line item Description #1 

FN_BENG_LN_ITEM_DESC 

Optional 

string 

36 

CC.SEJE 

Injtemjtesc2[1003 

Line item Description #2 

FN BENG LN ITEM DESC2 

Ootional 

>/MllVl lUl 

strina 

36 

CC,SE,TE 

pcnt_of_chg[100] 

Percent factor 

FN_BENG_PCNT_OF_CHG 

Optional j 

double 

8 

CC,SE,TE 

rct_chgjyp[100] 

Charge Type 

FN_BENGJRCT_CHG_TYP 

Mandatory 

string 

6 

CC,SE,TE 

rut_cd[100] 

Per hour,day,week,month charge 

FN_.BENG_RUT.CD 

Mandatory 

string 

4 

CC 

txcstrt_dt[10G] 

Tax/Surcharge start date 

FN_BENGJTXC_STRTJ)T 

Optional 

string 

9 

SEJE 

txc_tc_cd[100] 

Tax/Surcharge code 

FN_BENG_TXC_TX_CD 

Optional 

string 

16 

SE,TE 

tsjypecd[100] 

Tax/Surcharge type (ie. OPTL, 
ARPT) 

FN_BENG_TS_JYPE_CD 

Optional 

string 

5 

SEJE 

Taxable jnd[1 00] 

Taxable Indicator 

FN_BENG_TAXABLE J ND 

Mandatory 

char 

1 

TE 

inclusivejlg[100] 

Inclusive indicator for charge - Y- 
Incl, N-Notlncl 

FN_BENGJNCLUSIVE_FLG 

Mandatory 

char 

1 

CC 

allocation jnd[1 00] 

Allocation indicator - T-Tour, N- 
Driver 

FN_BENG_ALLOCATION J N D 

Mandatory 

char 

1 

CC 

bac_acct jdflOC] 

Business Account scienter 

FH„SEN3.BiLLTOJD 

Gpdoral 

tang 

4 

OA 

dvr_dvr_jd[100] 

Renter identifier 

FN_BENG_RENTERJD 

Optional 

long 

4 

CA 

rcc_chg_cat[100] 

Charge Category 

FN_BENG_CHG_CAT 

Optional 

string 

4 

CC 

r cL9*Lseq[1Q0] 

GL Sequence Number 

FN__BENG_GLT_SEQ__NBR 

Optional 

long 

4 

CC 

rcc__chg_seq[100] 

Charge Category Sequence 

FN_BENG_CHG_CAT_SEQ 

Optional 

long 

4 

CC 

rct_chg_seq[100] 

Charge Type Sequence 

FN_BENG_CHG_TYPE_SEQ 

Optional 

long 

4 

CC 

chg_stdt[100] 

Charge Start Date 
(YYYYMMDDHHMI) 

FN_BENG_CHG_ST_DT 

Mandatory 

string 

13 

CC 

chg_end__dt[100] 

Charge End Date 
(YYYYMMDDHHMI) 

FN_BENG.CHG_END.DT 

Mandatory 

string 

13 

CC 


Legend: CC = Charge Calculation, CA = Charge Allocation, SE = Surcharge Engine, TE = Tax Engine 


Last Save Date: 1 1 /5/2001 1 0:22 AM 


Page 22 of 51 


Charge Engine Detail Design_I3 



rent-a-car 


ECARS v2.0 - Accurate Out the Door Pricing 
Detailed Design Specification 


perotsystems- 


3.13 Detailed Process Flow 

Once a user's request has been transmitted through the Tuxedo interface, the charge engine driver 
n ROPTS0100A_SvcDataAccess" calls the following module in sequence - items which may be 
bundled into the Time-and-Mileage charge but not priced as a percentage of the T&M, are processed 
ahead of service module ropuOl 10. 


General Rental 
Processing 


Tuxedo Domain 


wrsoiooA 



Tuk: Server 


Client Domain 


[alt 

n 
5 

n s 

m 

sea' 

yj 


hi: 

ru 


Equipment 
ropu0120 


Coverage 
ropu0140 


Fuel Service 
ropu0150 


Time & Mileage 
ropuOHO 


1 


Del/Col 
ropu0130 



Discount 
ropu0170 


Ancillary 
ropu0160 


Differential 
ropu0230 


Coupon 
ropu0240 


Surcharges 
(BIL_Server) 


StateTaxes 
ROPTS0180 


3.13.1 Charge Engine Main Processor (ROPTSOlOOAjSvcDataAccess) 

Basic logic flow for the Charge Engine Tux server (ROPTSOlOOAjSvcDataAccess): 

Recalculate Units and Optimize based on charge frequencies 

WHILE a service module is defined 

DO 

Call the service module 

IF the service module fails THEN 

Terminate the whole transaction 

Skip - return error to caller 
END IF 
END WHILE 

IF all calculations were successfully made THEN 

IF further allocation is needed THEN 
Call allocation engine 

END IF 
END IF 

Copy results into CE ! s TUX output for caller's use 


Note: The allocation engine call will be activated in iteration 4. 
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3.1.3.1.1 Equipment Charges (ropu0120) 

This service module traverses a caller-supplied linked list of Equipment items and creates the rental 
and/or replacement charges for each item. On pickup, the charges for each equipment along with a 
possible replacement cost are computed - the activity code for the replacement line item is 4 NS> so it 
does not figure into the overall calculation but can be displayed to the customer. On return, if the 
replacement flag is set to 'Y' (FN BENG EOP . CHGS REPL FLAGl a single line item with that 
value is created and any equipment rental value is ignored. Each item in this list is used to retrieve 
the checkout charge rate and amount for the equipment. These values are then used to create charges 
for the equipment. If the charge is inclusive, the "back-out logic" is used to reduce the vehicle rate 
by that charge. 


FOR each basic equipment item specified 
IF replacement flag is set THEN 

Create the replacement charge as an "active-Show" item 
ELSE 

IF rateUnitType is "I" or f P T and there are inclusive items THEN 
Unbundle charges from Vehicle Rate and create EQP charges 
^sjj ELSE 

H IF rental count for this item is non-zero THEN 

|U Calculate a flat per Rental charge 

jS ELSE // (no flat amount charge) 

Zt total charges = sum of each rate bucket 

H IF total charges > MAX__RNT_AMT and MAX RNT AMT is not Zero THEN 

Disregard component charges 

Calculate a flat per Rental charge for MAX_RNT_AMT 
ELSE 

IF the monthly count is non-zero THEN 
Calculate a per month charge 

PI END IF 

jjlj IF the weekly count is non-zero THEN 

Calculate a per week charge 
END IF 

M IF the day count is non-zero THEN 

H Calculate a per day charge 

END IF 

IF the hour count is non-zero THEN 

Calculate a per hour charge 
END IF 
END IF 
END IF 
END IF 

Create the replacement charge as "not active-Show" item 
END IF 
END FOR 


Irs* 
5? 

jtsr. 


Refer to the input sub-section for required data on equipment charges. 

On exit, the program returns to ROPTS0100A_SvcDataAccess with a return code and an updated 
count of the charge line items. 
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3.1.3.1.2 Insurance Charges (ropu0140) 

This service module creates a charge item for each item in the Insurance Linked List. These charges 
may be zero-amount if the rate member of the list item is 0.0. Appropriate changes will be made to 
support the 'Daily', Weekly' and 'Monthly' charge frequency required for ECARS 2.0. There is also 
a charge for "excess deposit" (amount driver is responsible for before insurance pays out). If the 
charge is inclusive, the "back-out logic" is used to reduce the T&M value by that charge. 


FOR each item in the insurance list 
DO 

IF rateUnitType is T T r or f P T and there are inclusive items THEN 

Unbundle charges from Vehicle Rate and create INS charges 
ELSE 

IF the number of stag days is specified THEN 

See Flow chart below 
END IF 

IF the daily count is non-zero THEN 
lA Calculate a daily insurance charge 

!« END IF 

iwa IF the weekly count is non-zero THEN 

jjj* Calculate a weekly insurance charge 

hi END IF 

iSi IF the monthly count is non-zero THEN 

|*1 Calculate a monthly insurance charge 

Z] END IF 

/! END IF 

3 s 3 

Calculate "excess deposit" charge ('NS' activity code) 
{.* END FOR 

m 

f w 

yfThe following modification will be made to service module ropu0140 to implement staggered rates. 
^Bundled and staggered rates are mutually exclusive and bundled rates take precedence. 

Two additional input parameters dealing for staggered rates are added to the charge engine input 
section. After processing, two lines items for either PAI or PEC coverage types, will be created as 
described below: 


1 . Line item #1 is the regular daily amount (FN_BENG JNS_DY_RT) multiplied by the 
threshold number of days, defined as the number of days that the initial rate is charged. This 
number is specified in the field FNBENG_INS_DAYS. 

2. Line item #2 is the staggered premium amount (FN_BENG_INS_STG_RT) multiplied by 
the number of staggered days (FN_BENGJNS_NBR_STG_DAYS). This number defines 
the number of subsequent days beyond the threshold days. 
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S 
Q 

m 

m 


p3s 


« IS' 


Continue 
Normal 
Processing 



h. ^ stag .tat 


Ty 


Error - Return 
to caller 


Create line item 
for initial days 


Error - Return 
to caller 


< 



Create line item 
for staggered 
days 

1 



Done 


2= 


p Assuming a 4-day rental and PAI coverage with threshold days set at 3 days ($2.00 per day) and 1 
"i staggered day ($1 .00), the Charge Engine will create two line items as follows: 

Line #1 : PAI: 3 days at $2.00 = $6.00 (Day 1 , 2 and 3) 
Line #2: PAI: 1 day at $ 1 .00 = $ 1 .00 (Day 4) 
Total =$7.00 

On exit, the program returns to ROPTS0100A_SvcDataAccess with a return code and an updated 
count of the charge line items. 


3.1.3.1.3 Fuel Charges (ropu0150) 

Most of the calculation methods used in VRS will be disabled . The refueling service accepts a 
refuel cost and quantity (fuel consumed - ) from the client application and generates a line item for 
Refueling based on those numbers. A modification to the input section now accepts the fuel 
payment typ e output by the Ancillary engine. This field is used to create the refuel line item with the 
a ppropriate charge type. 

The ability to unbundle fuel price from the vehicle rate will be retained. 
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For the Enterprise implementation, a new calculation method will be created to accept the unit value 
(FN_BENG_RFLG_QTY) and the unit cost (FN_BENG_RFLG_COST) from the client application. 
After design review with the customer on June 6, 2001, it was decided that the fuel_prcs table will be 
used to maintain refuel prices. The ancillary charge engine will be used by the client application to 
retrieve two cost figures (pre-paid and post-paid). Please refer to the design document of the 
Ancillary service for the interface description. Only one of those figures will be passed to the charge 
engine depending on user selection. The client application also passes an appropriate unit count 
(number of gallons/liters) to the charge engine. It also has the option of pre-calculating the total 
refuel amount, in which case the number of gallons (unit count) passed to the charge engine would 
be set to 1. In order to c ause the refuel line item to be calculated, the client application should also 
set the calc mode input parameter to 'IP (TN BENG CALC MODE) and 
FN BENG RFLG PAY TYPE to the payment type returned bv the Ancillary engine f F-prepav or 
P- postpav). 

On exit, the program returns to ROPTS0100A_SvcDataAccess with a return code and an updated 
Q count of the charge line items. 

fi 

■SIS 8 

lU 

0? 3.1.3.1.4 Vehicle Charges/Time & Mileage (ropuOHO) 

O 

There are three "types" of rate units supported in VRS - Time and Mileage (TM), Packages (PKG) 
- and Variable Rate (VAR). These are mutually exclusive for any rental. For ECARS 2.0, only the 
;\ TM rate type will be used through iteration 3. Rate types PKG and VAR will be disabled. Ifthe 
h j vehicle rate for the rental includes taxes and surcharges, those charges are backed out from the 
|1J vehicle rates. Government taxes and surcharges are calculated based on the reduced vehicle rate. 

pFor 'Reservation', 'Open Ticket', and 'Modify Ticket' modes, zero duration charges are created for 
U any rate unit bucket for which the duration is zero. For example, ifthe monthly rate is populated, but 
the number of months charged at this rate is 0, there will be a charge line item created with its charge 
unit and the amount fields set to 0. This allows all of the different rate buckets to be displayed on the 
rental agreement and reservation disclosure screens ifthe GUI so desires. 

Tax-inclusive and surcharge-inclusive rates are indicated via the FN_BENG_INCL_FLAG and the 
FN_BENG_SRCHG_INCL_FLAG input parameters respectively. 

This module also calculates the mileage cost to be assessed for the rental - Ifthe excess mileage rate 
input parameter is zero, there will be an UNLIMITED JV1ILEAGE charge line item (zero amount) 
created. Otherwise (excess mileage rate non-zero), there will be a (zero-amount) free miles charge, a 
(zero-amount) charge for any "extra" free miles (free miles associated with "extra" or "extension" 
rental periods) and a charge (non-zero) amount) for any mileage above the sum of all "free" miles. 
Basic flow for the T&M module follows: 

IF rate type = ? T f (Time and Mileage rate) THEN 
Process Monthly charge if specified 
Process Weekly charge if specified 
Process Daily charge if specified 

Process Hourly charge if specified 
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Process Extra-Weeks charge if specified 
Process Extra-Day charge if specified 
Process Extra-hour charge if specified 

IF excess mileage rate is zero (mileage is unlimited) THEN 

create UNLIMITED miles charge 
ELSE (mileage is NOT unlimited) 

create FREE miles charge 

create "extra" FREE miles charge 

IF totaljniles > allowed free miles THEN 
create excess mileage charge 
END IF 


ELSE (not TM) 

error - unknown rate type 
END IF 


For this release of the Enterprise implementation, the mileage allowance is expected for only a single 
product instance. In future iterations, when repeating groups are introduced for products, this 
module would have to be modified to take into account differing amount for mileage allowance 
^across all products and generate a charge line accordingly. Rate type r P and 'V 1 will not be supported 
On VRS until the applicability of those rate types are properly defined for ECARS 2.0. 

■SIS si 5 

Jlpn exit, the program returns to ROPTS0100A_SvcDataAccess with a return code and an updated 
pijbount of the charge line items. 


13.1.3.1.5 Drop Charges, Delivery and Collection (ropu0130) 


^I>rop Charge: 

hi 


gflThe charge engine creates a line item for this charge type based on the data passed to it. There is not 
l!|tnuch logic behind it. The only requirement is that the f one_way_tarifF input parameter be non-zero. 

p. 

This fee may be prepaid when used with a package product and the override flag for drop charge is 
set as a contractual condition. The charge engine will group this charge together with all other 
charges that would be allocated to the business account behind the voucher. That charge will be 
above the value of the voucher used for the rental. For example, if a voucher is worth $100.00 and 
there is a $35.00 prepaid drop fee, the business account for that voucher will be billed $135.00. 
Outside of prepaid products, drop charges are treated as any other charge line item. The program 
flow is shown below: 


IF one_way_tarif f (input parameter) is non-zero THEN 
Create a line item for drop charges 

IF rate unit type is PKG and the fee is prepaid THEN 

Mark the line item so that it will allocated to Tour Operator 
END IF 
END IF 
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Delivery and Collection Charge: 

Current logic creates flat amount charge for delivery and collection. The flat amount can include a 
per unit charge, but will show as a flat amount charge on the RRA_CHGS list. The flat amount is 
determined as follows: 


There is a flat fee up to some base number of units. For units beyond this base amount, a per-unit 
charge is applied. The charge amount is the sum of these (flat fee and per unit fee). For unit types 
other than distance, a flat fee is applied. 
Basic logic flow for delivery charge calculation is: 

IF del_comb_flag is T Y 1 or 'N' THEN 

use "in" parameters for delivery charge 
ELSE 

use "out" parameters 
END IF 

IF the delivery charge is a "per distance unit" charge THEN 
jr]j IF the units used is more than the free units allowed THEN 

Calculate the additional charge based on distance 
ll* Charge Amount is fixed amount plus additional charge 

MJ end if 

0) ELSE 

Q charge amount is passed in (fixed amount) 

END IF 

S „ H 

W IF the charge amount is not zero THEN 
si create the delivery charge 

l vA END IF 

!!i 

lljBasic logic flow for collection charge calculation is: 

||1 

ih IF col comb flag is T Y T or f N ! THEN 

i ' use "in" parameters for collection charge 

F * ELSE 

use "out" parameters 
END IF 


IF the collection charge is a "per distance unit" charge THEN 
IF the units used is more than the free units allowed THEN 

calculate the charge amount based on distance 
END IF 

ELSE 

charge amount is passed in (fixed amount) 
END IF 

IF the charge amount is not zero THEN 

create the collection charge 
END IF 


This functionality will not be used in Iteration 2 or 3 of the ERAC implementation. 

On exit, the program returns to ROPTS0100A_SvcDataAccess with a return code and an updated 
count of the charge line items. 
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3.1.3.1.6 Discount Credits (ropu0170) 


The handling of discounts is processed in module ropuOl 70.pc. Current logic creates a discount line 
item if the total Basic Rental Charges are non-zero and the 'disc_pcntage' parameter passed by the 
caller is non-zero. This charge is created as a percentage of the vehicle rate. The discount will 
always be applied to the time and mileage charges even when other charges are bundled into the 
vehicle rate. For future release of ECARS 2.0, a discount applicability flag and a method for 
denoting whether a charge type is discountable, will be added as an input to the charge engine so that 
the actual discount may be applied to one of the following charge items: 

1. Time only (T) 

2. Time and Mileage (M) 

3. Total Rental amount for discountable charges before tax (R) 

The applicability flag drives the selection of one of the above options. Note that for options 1 and 2, 
j,=the discountable indicator is not taken into account, as the directives are explicit. When option 3 is 
Cjselected, the charge engine will calculate the basis for the discount using all charge types (in the 
Qcurrent ticket) deemed to be discountable. 

\M 

gjlteration 2 of ECARS 2.0 will apply the discount to the sum of the vehicle rate, mileage and upgrade 
j~|charges. This will be the default behavior until future iterations when the applicability flag is 
processed. A DDL change to the RRAJ3HGJYPS will be made so that each charge type can be 
■^defined as being discountable or not. This service module will take that indicator into account when 
^calculating the cost basis for the discount. Any discount functionality, from a testing perspective, 
n iwill be deferred to iteration 4. 

w 

fjlCurrent logic flow for discount charge calculation is: 

s-jI IF the discount percentage (input parameter) is non-zero THEN 

Calculate Rental Charges per specified option 
IF total basic rental charges is non-zero THEN 

Create a (percentage) discount charge 
END IF 
END IF 

On exit, the program returns to ROPTS0100A_SvcDataAccess with a return code and an updated 
count of the charge line items. 
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3,1.3.1.7 Ancillary Charges (ropu0160) 

Ancillary charges are "non-standard" charges that the charge engine generates. The basis or the 
supported data for those charges does not necessarily come from the rate engine. Currently, there are 
5 such charge types defined, the first three of which will be implemented by a new VRS Engine. 
Calling processes must call the new service before calling the charge engine and copy any returned 
data into the input structure. 


1. After Hours 

2. Young Renter Fee 

3. Additional Driver 

4. Manual or Miscellaneous Charges 

5. Customer Satisfaction Credits 


The Charge Engine loops through this list and creates a charge for each valid item. This approach 
f** was taken to allow additional charges to be identified and added later with minimal impact and 
p interface changes. These charges can be per rental, per day, or percentage-based, driven by the 
pchgjinitjyp field of the input structure. 


j?3 Basic logic flow for allowance charge calculation is: 


s FOR each item in the ancillary charge list 

DO 


IF the chg_unit_typ is per rental ( *R f } THEN 

5: Create a fixed *Per Rental' amount charge 

L ELSE IF the chg_unit_typ is daily ( T D ' ) THEN 

|j* IF the Calc Amount greater than MAXIMUM and MAXIMUM is not Zero THEN 

!1J Disregard the x Per Day' component ~~~ 

f|l Create a fixed x Per Rental' charge using MAXIMUM value 

isss, ELSE 


Create a *Per Day' charge 
END IF * 

ELSE IF the chg_unit_typ is percent ('C') THEN 

Create a 'Percentage-based' charge 
END IF 
END FOR 


Current VRS implementation allows 'Per Rental 1 charges for 'After Hours' and 'Per Rental' / 'Per 
Day' for 'Additional Driver' and 'Young Driver 9 . 

On exit, the program returns to ROPTSOlOOAJSvcDataAccess with a return code and an updated 
count of the charge line items. 


3.1.3.1.8 Location Differential (ropu0230) 

This is an output of the rate engine. The Charge engine will create a charge item based on the 
parameters passed. 

Basic logic flow for location differential charge calculation is: 


Last Save Date: 1 1/5/2001 10:22 AM 


Page 31 of 5 2 


Charge Engine Detail Design_I3 


rent-a-car 


ECARS v2.0 - Accurate Out the Door Pricing 
Detailed Design Specification 


perotsystems 


IF the differential amount is non-zero THEN 

Create a location differential charge 
END IF 

This functionality may not be used in ECARS 2.0. 

On exit, the program returns to ROPTS0100A_SvcDataAccess with a return code and an updated 
count of the charge line items. 


3,1.3.1.9 Coupon Credits (ropu0240) 

The Charge engine calls the Coupon Valuation Service passing up to three coupon identifiers as 
defined in the interface. The Coupon Valuation Service is a library routine (MKTB7020) 
implemented in the Coupon Design part of VRS. It will return a charge amount for each coupon id, 
which may be zero. A charge line item is created for each coupon with a non-zero value. There may 
be a multiplier for each coupon id, in which case the charge would be the total of all coupons with 
l^that coupon id. The charge engine creates an adjustment line item if the value of the coupon exceeds 
pthe basic rental cost. This item is listed as a negative number and is defined as a forfeited amount. 

[USimilar to discount, the value of the coupon is determined using the effective T&M as the basis in 
Please there are bundled charges. 


In* 


fBasic logic flow for coupon charge calculation is: 


Ill 


m 

i » 


IF there are any coupon id's passed in THEN 
Calculate the 'minimum-daily 1 rental amount 
Call coupon valuation service 
FOR each coupon id passed in 
DO 

IF coupon value is non zero THEN 

Add coupon amount to total_coupon_amt 
l Create coupon charge (negative amount) 

END IF 
END FOR 

IF (total_coupon__amt > basic_rental_total) THEN 

create coupon adjustment charge (forfeited amount) 
END IF 
END IF 

The following table is required to support the valuation service. 

COUP EROMO VALD 


Columns 

COUPON_ID 

CPN_CREATEJDT 

DT_DEPOSIT_ID 

PROM_COUP_IND 

BUA_ACCT_ID 

CON_CON_ID 

CPN_CHG_DT 

CPV__CAPACITY_CONT_FLG 
CPV_COMMENT 
CPV_C0NT_TRK_L I S TJNM 
CPV CUST VAL AMT 


VARCHAR2 (10) 
DATE 

NUMBER (1) 
VARCHAR2 (1) 
NUMBER (8) 
NUMBER (8) 
DATE 

VARCHAR2 (1) 
VARCHAR2 (35) 
VARCHAR2 (15) 
NUMBER (15, 3) 


NOT NULL 

DEFAULT SYS DATE NOT NULL 
DEFAULT 7 NOT NULL 
NOT NULL 


DEFAULT f N' 
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CPVEXPIREJDT 

CPV_MAX_QTY 

CPVJJAME 

CPV_TYPE_CD 

CPV_VALUE_INTNL__AMT 

CUR_CURR_CD 

GTR_GLT_SEQ 

RCT_RRA_CHGJTYP 

PAPERJELECT_CD 

Primary Key 
COUPON ID 


DATE 

NUMBER (1) 
VARCHAR2 (35) 
VARCHAR2 (2) 
NUMBER (15, 3) 
VARCHAR2 (3) 
NUMBER (6) 
VARCHAR2 (5) 
VARCHAR2 (1) 


DEFAULT ! UG' 


DEFAULT 'USD' 


Indexes 


Foreign Keys 

CPV__BUA_FK (BUA_ACCT_ID) REFERENCES BUS_ACNTS (ACCT ID) 

CPV_CON_FK (C0N_C0NJED) REFERENCES CONS (CON_ID) 

CPV_CUR_FK (CUR_CURR_CD) REFERENCES CURRS (CURR_CD) 

CPV_RCT_FK <RCT_RRA_CHG_TYP) REFERENCES RRA_CHG TYPS (CHG TYP) 


US 


Check Constraints 

VALID_RULE625 ( cpv_capacity_cont_f lg IN ( 'Y 1 

VALID_RULE624 ( cpv_type_cd IN ( 'UG 1 , 1 FD 1 , 

SYS_C00257Q ( prom_coup_ind IN ( 1 P f , 1 C T } ) 


, T N ' 
f C0 f 


) ) 
) ) 


k|Al the charge engine level, the SQL to support coupon valuation using the above table would be as shown 
^below: 


ha 


fij 

m 


SELECT cp.cpv_type_cd, 

DECODE(cp.cpvJype_cd, VQ\ 0, 

TD\ (LEAST( 


((:basic_rental/:rentaljength)*cp.cpv_cust_val_amt), 
(:lowest_dailyrate*cpxpv_cust_val_amt))), 
cpxpv_cust_val_amt) coupon_val, 


cp.couponjd, 
cp.dt_depositjd 5 
cp.rct_rra_chg_typ, 
cp.cpvjiame, 
cp.cpv_comment 
FROM VRS.coup_promo_vald cp 
WHERE cp.couponjd in (xoupl Jd_val, 

:coup2_jd_val, 
:coup3Jd_val); 

The intent is to disable the coupon valuation service until that part of VRS is folly implemented in 
ECARS. 


On exit, the program returns to ROPTS0100A_SvcDataAccess with a return code and an updated 
count of the charge line items. 
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3.1.3.1.10 Surcharges (ropu0220) 

Once all the charges for a given rental are created, the surcharge service module (ropu0220) is called 
to calculate the surcharges, if applicable. A surcharge is calculated for each charge type found but is 
summarized and grouped by surcharge id so that a single value is returned to the caller program. A 
more detailed breakdown of surcharges is decribed in the Surcharge Engine Design document. 

Basic flow logic for these surcharges is: 

Initialize array of surcharge information, one element for each possible surcharge 

FOR each charge we have created so far 

DO 

Call surcharge tuxedo service to calculate surcharges 
Accumulate surcharge information into local array 
END FOR 

FOR each item in the surcharge array 

' Ll DO 

j** IF the surcharge is a Fixed Amount - 'per Rental 1 THEN 

53 Create a flat amount charge for the surcharge (ONCE) 

O ELSE IF the surcharge is a Fixed Amount - f per Day T THEN 

p| Create a per day charge for the surcharge (ONCE) 

fa ELSE IF the surcharge is a Percentage of Basic Rental THEN 

jjjjjj Create a percentage-based surcharge 

'bp ELSE 

h 'H ERROR - unknown surcharge type 

hj END IF 

Adjust for MIN and MAX for each created charge line item 
END FOR 

If jjThe charge engine interfaces to the surcharge engine via a wrapper program defined as shown below. 
jjijThe formal parameter list has been modified to include certain arguments that must be passed to it 
jgfor the ECARS 2.0 implementation. No specific use has been defined for the 'walkin fig' and the 
li ' waive arpt fee flg\ consequently their default value of C N* will be used. 


int FindSchgs ( char 

*co_cry, 

/* Country code */ 

char 

*co_date, 

/* Checkout date */ 

char 

*ci_date, 

/* Check-in date */ 

char 

*co_stn, 

/* Checkout station */ 

char 

*co_state_cd, 

/* State code for pickup branch */ 
/* Charge type */ 

char 

*chgjyp, 

double 

chg_amt, 

/* Charge amount */ 

char 

*vhcl_cat_cd, 

/* Vehicle category */ 

long 

vhcl_unit_nbr, 

/* Vehicle unit number */ 

char 

*vhcl_pvro_st, 

/* Vehicle Owning State */ 

long 

zip_cd, 

/* Exempted zip code */ 

char 

tx_exmpt_flag, 

/* Tax exempt indicator */ 

long 

conjd, 

/* Contract ID */ 

long 

rntljiays, 

/* Rental duration */ 

long 

basejiays, 

/* Base days */ 

long 

extra_days, 

/* Extra days */ 

long 

extension_days, 

/* Extension days */ 

char 

counterjd, 

/* Counter ID */ 

char 

walkin__flg, 

/* Walkin Rental Flag (Y/N). Default = N */ 
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char waive_arpt_fee_flg, /* Waive Concession Fees (Y/N) */ 

char rent_type_cd s /* Specific Code identifying type of rental */ 

double vhcl_weight, /* Vehicle weight in tons */ 

double vhcljrice, /* Vehicle price - currency ??? */ 

double Annual_vl£, /* Vehicle registration cost */ 

char *vhcl_reg_exp_dt, /* Vhcl reg expiration YYYYMMDD */ 

char *vhcljype, /* Vehicle type, CR=Car,TR=Truck */ 

char *vhclj-eg_cry, /* Vehicle registration country (US) */ 

double ytd_vlf, /* Year-to-date Vehicle License Fee */ 


struct out_schgs *out ); /* Output Structure returned to caller */ 


The output structure (out__schgs) returned to the Charge engine is defined in the Surcharge Engine 
Design document. 

When a v ehicle identification number is not provided ( as might be the case during reservation \ 
yVLE (Vehicle License Fees) will be provided as two separate items (a minimum and a maximum). 
CpQth line i tems will have a 'NS' (Not-Active. Show) activity code so that they do not factor in the 
recalculated rental estimate. However, they can be used to provide disclosure as to what the final cost 
p jfor that item will be at closing. 

„ .— 

^jOn exit, the program returns to ROPTS0100A_SvcDataAccess with a return code and an updated 
yjbount of the charge line items. 

H 

H&.1.3.1.11 Sales Tax Charges (ropu0180) 

ill 

UPnce all charges pertaining to this rental have been calculated and surcharged, the tax service 
!;^odule is called to calculate any applicable taxes. Similar to surcharges, the charges are 
* summarized and presented as a single line item. In countries such as Canada, where there is more 
than one sales tax type, the charge engine will generate one tax line per tax id. 

The tax service module loops through all charges created thus far, retrieves tax data for checkout 
country and charge type from cache or the database, and calculates the applicable taxes, 
accumulating the tax amounts for all tax levels across calls (for each charge). Specific details of the 
TAX Engine are provided in the Tax Engine Design document. 

Basic logic flow for tax charge calculation is: 

Initialize array of tax information, _one element for each possible tax level 

FOR each charge we have created so far 

DO 

Call tax tuxedo service to calculate taxes 
Accumulate tax information into local array 
END FOR 

FOR each item in the tax array (each "level") 
DO . 

Create a line item for the tax 
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END FOR 

Adjust created line items with respect to MAXIMUM tax 


The calculation itself is not performed in ropuOl 80. Rather, a Tuxedo server implements the tax 
engine and the following wrapper program is used for easy access. 


int FindTaxes( 


double 

amt, 

/* Tax Basis */ 

char 

*chgjyp, 

/* RCT charge type */ 

char 

*cq_cry, 

/* Checkout country code */ 

char 

*co_stn, 

/* Checkout station */ 

char 

*cojstate_cd, 

/* State code for pickup branch */ 

char 

*co_date, 

/* Checkout date */ 

int 

exempt_flag, 

/* Exempt flag */ 

/* indicate whether charge is taxable */ 

int 

*tax_applied, 

char 

*schg_id, 

/* Is this a surcharge */ 

long 

conjd, 

/* Contract ID*/ 

char 

counter Jd, 

/* Counter ID within station */ 

struct out jropsjtax 

*save, 

/* Output structure - Accumulated values */ 

double 

*tax_val ); 

/* Individual item tax */ 


u 

lU 

»*jlhe output structure (outjropsjax) returned to the charge engine is defined in the TAX Engine 
bJDesign document. 

^ Currently, the charge engine does not display 0 tax lines, but Gap 30 requires a change to that logic 

jl Jso that exempted tax line items can be created Whereas VRS used the activity code 4 NN ? to 

jl Jeffectivelv exclude exempt taxes from overall calculation. ERAC requires that the Tax Engine zeroes 

jj jthe amount that would normally be charged. The charge engine will be modified to not ignore zero 

^amounts. 

On exit, the program returns to ROPTS0100A_SvcDataAccess with a return code and an updated 
count of the charge line items. 

3.1.4 Optimization 
3.1.4.1 Unit Recalculation 

The charge engine recalculates the unit count for each charge frequency and optimizes as necessary 
taking into account the billing cycle and the available rate buckets. For example, a weekly rate 
might be offered for a 5-day rental if the total is less than the daily rate times 5. The client 
application has the option of forcing the charge engine to accept the input parameters as specified by 
setting the FN^BENG_RECALC_UNIT__FLAG to 4 N' . Unit recalculation is performed for the 
following charge types: 

• Vehicle Rates 

• Equipment Charges 
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• Coverage Charges 

• Ancillary Charges 

Each charge type is processed independently of the other. No optimization is performed if the billing 
cycle is Calendar as the implication is that only daily rates are valid. Also, provision is made so that 
a 1-day rental spanning 2 calendar days evaluates to 1 day if the total elapsed time does not exceed 
24 hours. However, once the rental duration exceeds 24 hours, the total number of days charged will 
be based on the number of spanned calendar days. For example, a 36 hour rental (Tuesday 20:00 to 
Thursday 08:00) would evaluate to 3 days. 


3.1.4.2 Vehicle Exchange 

ERAC requires that the licensing fees for each vehicle used in a ticket to appear as a separate line 
item.^ The charge engine needs to call the surcharge engine for each vehicle movement with different 
duration values. In order to achieve that, the client application should ensure that a matched set of 
rjvehicle and rate structures exists. The charge engine input interface has been modified to separate 
;.=jvehicle and rate groupings to allow that. Since each rate structure is optimized separately, it is 
•^possible to generate delta duration values that do not add up to the rental duration. In order to avoid 
yfthat problem, the following rules will be utilized: 

Sirs 1 

0 

Cj24-Honr Billing Cycle: 

i.i 

* 1 . The start date for each exchange will be the Exchange date and the start time will be the 

I* Pickup time or the actual Exchange time whichever is earliest. The end date and time will be 

Hi the return date and time. 

Hi 

2. The end date and time on the rate for the previous vehicle used will be the start date and time 
J*f of the exchange minus 1 second. 

Calendar Billing Cycle: 


1 . The start date and time for each exchange will be the exchange date and midnight The end 
date and time will be the return date and time. 

2. The end date and time on the rate for the previous vehicle used will be the date prior to the 
exchange at 23:59. 

The diagram below illustrates this: 
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Dayl 


Day 2 


|™1 


fir* 
3 



Actual Exchange 
Transaction 
Date and Time 

Modified Exchange 
Transaction 
Date and Time 
24-Hour Cycle 

Modified Exchange 
Transaction 
Date and Time 
Calendar Cycle 


Vehicle Exchange on Day 2 
At 16:00 


00:00 


hi 


y?By creating two rate structures with the start and end periods as shown above, the charge engine will 
ji^be able to calculate VLF (Vehicle License Fees) for each vehicle used in the ticket by using different 
{^duration values when calling the surcharge engine. This assumes that on the day of exchange, the 
" VLF will be charged against the vehicle to be exchanged for that full day. For calendar billing cycle, 
a full day begins at midnight - for 24-hour billing cycle, a full day begins at the Pickup time. 


3.1.4.3 Special Product Handling 


The method for handling specials by the charge engine is similar to the discussion above with respect 
to vehicle exchange. Essentially, a ticket based on a special product will consist of 3 rate periods 
presented to the charge engine as three independent occurrences. Since ERAC has requested that 
each occurrence be optimized independently, this fits in well with the multiple grouping design. The 
definition and specific requirement for Specials are covered in the Rate Engine Design document. In 
this document, the focus is on the necessary transformation of the data returned by the rate engine for 
charge calculation and eventual allocation. 

The three rate periods are defined as the "Before Special", "Special" and "After Special". The 
before and after periods share the same cost figures and the special period has its own. Each period 
is optimized separately. The Client application is expected to provide the start and end date/time for 
each period and maintain 24-hour increment for the period before the special. If the whole rental 
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falls within the special period, it is not necessary to provide a 'before 5 and 'after' rate grouping as 
shown below unless there is a requirement to disclose to the renter what the cost will be if the pickup 
and return date/time changes. 


Charge Engine numerate parameter - 3 


Pi 


Rate Engine Outpui 


Pickup dt-tm 


Earliest Special Start dt 
Latest Special End dt 
Special Daily Count 
Special Daily Bate 
Special Daily Miles 


Before Day Count 
Before Week Count 


Hourly Rate 
Hourly Miles 
Daily Rate 
Daily Miles 
Weekly Rate 
Weekly Miles 
Monthly Rate 
Monthly Miles 


After Hour Count 
After Day Count 
After Week Count 
After Month Count 


Return dt-tm 


Day Count 
Daily Rate 
Daily miles 
Week Count 
Weekly Rate 
Weekly Miles 
(Before Start dt-tm) 
(Before End dt-tm) 


Day Count 
Daily Rate 
Daily miles 
Special Start dt-tm 
Special End dt-tm 


Hour Count 
Hourly Rate 
Hourly Miles 
Day Count 
Daily Rate 
Daily miles 
Week Count 
Weekly Rate 
Weekly Miles 
Month Count 
Monthly Rate 
Month|r Miles 
(After Start dt-tm) 
(After End dt-tm) 


Before 
Special 


Special 


After 
Special 


Hi 

3<fS 


jj~For each of the scenarios described in the Rate engine document, the inputs to the charge engine with 
prespect to start and end date and time, are populated as shown below. The qualifications for the 
pSpecial product is 'Earliest Pickup' - Thursday at 12:00PM and 'Latest Return' - Monday at Pickup 
Time. 


Scenario 1 : Entire rental falls within the Pickup earliest and return latest days for Special: 



Charge Engine 
Rate Ovcunxmcv - ! 

Charge Engine 
Rate Occurrence - 2 

luxe Occwr&tcv ~ 3 

Pickup -200108091300 




Return-200108131100 




Before Special Start 




Before Special End 




Special Start (200108091200) 


200108091300 


Special End (200108131200) 


200108131100 


After Special Start 




After Special End 
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Scenario 3 : Return is after th e return latest day for 


Special: 




Charge Engine 
Rate Occurrence - 2 

Charge Engine 
Rate Occurrence - 3 

Pickup -200108101300 




Return -200108141 100 




Before Special Start 




Before Special End 




Special Start (200108091200) 


200108101300 


Special End (200108131200) 


200108131300 


After Special Start 



200108131301 

After Special End 



200108141100 


Scenario 4 : Pickup is same da y as earliest Pickup day - Agent overrides time: 


Hire Occurrence - f 


Charge Engine 
Rate Occurrence - 2 


Pickup -200108091000 


Return -200108130800 


■ Before Special Start 


^Before Special End 


^Special Start (200108091200) 


200108091000 


.Special End (200108131200) 


200108130800 


a I After Special Start 


10u I f)$ 130x00 


I After Special End 


Scenario 5 : Override earliest pickup day of week so that Special can be offered: 


: 

Charge Engine 
Rate Occurrence - 1 

Charge Engine 
Rate Occurrence - 2 

Untrue trg-<c 
Rate Occam- tJVx i 

« .Pickup- 200108081500 




."Return -200108131 100 




« -Before Special Start 

200108081500 



] ^Before Special End 

200108091459 



f Special Start (200108091200) 


200108091500 


? * Special End (200108131200) 


200108131100 


After Special Start 



2001OSJJH00 

After Special End 





Scenario 6 : Override earliest pickup day of week so that Special can be offered. Rental also 



Charge Engine 
Rate Occurrence - 1 

Charge Engine 
Rate Occurrence - 2 

Charge Engine 
Rate Occurrence - 3 

Pickup -200108081500 




Return-200108141100 




Before Special Start 

200108081500 



Before Special End 

200108091459 



Special Start (200108091200) 


200108091500 


Special End (200108131200) 


200108131100 


After Special Start 



200108131100 

After Special End 



200108141100 


To summarize, the charge engine processes each occurrence of the vehicle rate data as any other 
ticket with one rate occurrence. Although the input structure to the charge engine was modified with 
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repeating groups to support multiple products within the same ticket, that structure lends itself well 
for handling specials also, although the specified product for all 3 occurrences will be the same. The 
time period from one occurrence to the next is assumed to be in 24-hour increments - Refer to the 
assumption list in the Rate engine design. 


3.1.5 Calling Processes Variations 

This section is provided to give a sample of calls to the charge engine. The examples are taken 
directly from the Consolidated VRS Proposed Solutions' document, section 4.2.3. The normal 
process for using the services of the charge engine is to first obtain the necessary information for 
creating line item charges. This process would involve a call to the rate engine to obtain rates at 
some point during the rental process and calls to other engines as required to obtain data for ancillary 
charges. 


□ 


Ill 


lis 
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A representative sequence of calls follows: 


BEGIN 

IF reservation or a ticket without res THEN 
Call rate engine to obtain rates 

ELSE 

Use rates for Ticket from "saved" information 
END IF 

Call ancillary engine as needed 

Populate all charge engine required inputs 
Call the Charge Engine 

Process the returned output (line items) 

END 


3.1.5.1 Reservations 

s A reservation is made using the 800 number for pickup at the St Louis airport on March 21 st . No 
p "specific product is requested. A representative set of data is shown in the example below. 

jig 1 . Call the product rate service to get the rates for the default retail product 

m 2. Call the ancillary engine to get the rates for Young Renter', 'Additional driver' and 'After 

Q Hour' charges as required. 

SJ 3. Populate the charge engine input fields (make sure all mandatory fields are accounted for), 

y j 4. For estimate and disclosure purposes, the parameters for the requested car class could be 

specified (if known) to get more accurate surcharges. 

jJJ* 5. Call the charge engine using a Tuxedo system call 

J jf 6. Process the charge engine output 



: calLmode 

RS 

co_date 

200106040800 

co_cry 

US 

co_curr 

USD 

co_stnjd 

0110 

constate _jd 

MO 

djtete , " - U 


mm 


RentaLduration 

3 

num_rate 

1 

Prodjnst_cd 

DEFLRET 

vhcl_class 

ICAR 

vhcLclass_sfx 

01 

tm_days 

3 

tm_daily_rate 

33 
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Errorjio 


errjext 


sqLerrorjio 


sqLerror Jext 


Amount 


Num_charges 


115.41 


chg_acty 


AS 


AS 



chg_amt 


99.00 


0.00 


9.90 


chg_basis 


99.00 


chg_rt 


33.00 


0.00 


ltem_qty 


chg_unit 


Injtemjtesc 


in item desc2 


Time& 
Distance 


Unlimited 
Distance 


Concession 
Recoupment 


3 u 

S 


Pcnt_of_chg 


10.00 


rct_chgjyp 


00001 


00029 


00025 


rutcd 


- txc strt dt 


20010401 


5 15 
v™3 


txc tc cd 


US4STARP1 


as_type_cd 


OPTL1 


taxable ind 


inclusive Jig 


. allocation ind 


bac acct id 


N 


N 


N 


N 


dvr dvr id 


Iljrcc_chg_cat 


RNT 


RNT 


SUR| 


u 


rct_glt_seq 


628 


628 


445 


rcc_chg_seq 


' rct_chg_seq 


1 


8 


chg_st_dt 


200106040800 


200106040800 


200106040800 


chg_end_dt 


200106070800 


200106070800 


200106070800 


3.1.5.2 Open Ticket 

At pickup, the client application has the option of re-rating an existing reservation by calling the 
product rate service again or simply use saved information to populate the input fields of the charge 
engine. 

The process is similar to the one for Reservations except that the calljnode input parameter is now 
'CO 1 . Vehicle parameters may be provided at this time, in which case, the Vehicle License Fee item 
will be a single 6 AS - Active-Show' line with the actual amount to be charged instead of the MIN 
and MAX lines. 
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3.1.5.3 Modify Ticket 

A ticket, while in Open status, can be modified in a number of different ways. When a modification 
is made, usually in the length of the rental, a call to the rate engine is not always necessary unless 
there is a need to re-rate. The charge engine will automatically recalculate new unit counts based on 
the new rental end date/time and the charge frequency amounts that are populated (monthly, weekly, 
daily and hourly amounts). Additionally, it will optimize the counts by substituting for example a 
weekly rate for situations where the daily rate times the number of days would yield a higher 
amount. This process can be disabled by the client application - in that case, the charge engine will 
use the counts passed to it. Below are two examples of a 'Modify Ticket' situation. 


3.1 .53.1 Rental Duration Changes 

5*3 1 . Get the rental information on open ticket 

p 2. Populate the charge engine input fields (ensure all mandatory fields are accounted for). 

f\l 3. For estimate and disclosure purposes assuming that a vehicle is assigned, all vehicle 

£1! parameters could be specified to obtain accurate surcharges. 

Q 4. Call the charge engine using a Tuxedo system call 

N 5. Process the charge engine output 

w 

iii 



balLmode 

CO 

bo_date 

200106040800 

to_cry 

US 

co_curr 

USD 

co_stnJd 

0110 

constate Jd 

MO 

cLdate 

200106080800 

ci_cunr 

USD 

ci_stnjd 

0110 

rental_duration 

3 

numerate 

1 

prodjnst_cd 

DEFLRET 

efLstart_dt 

200106040800 

eff_end_dt 

200106040800 

vhcLciass 

ICAR 

vhcl_c!ass_sfx 

01 

tm_days 

3 

tm_daHy_rate 

33 
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error_no 

0 







errjext 








$qLerror_no 

0 







sql_errorJext 








amount 

153.88 







num_charges 

6 







chg_acty 

AS 

AS 

AS 

AS 

^^^^ 


AS 

chg_amt 

132.00 

0.00 

O.OO 

13.20 


10.00 

8.68 

chgj>asis 




132.00 



145.20 

chgjt 

33.00 

0.00 

4,42 



2.50 


item_qty 

1 

1 

1 

1 


1 

1 

chg_unit 

4 

0 

0 



4 


injtemjtesc 

Time & 
Distance 

Unlimited 
Distance 

Refueling 
Service 

Concession 
Recoupment 

; Registratipn Fee 


State Tax 

Injtem_desc2 








pcnt_of_chg 




10.00 



5.98 

: rct_chgjyp 

00001 

00029 

00022 

00025 

■■m 

00074 

00050 

rut_cd 

D 

R 

R 

C 


D 

C 

txc strt dt 




20010401 


20010401 

20010401 

txc tc cd 




US4STARP1 

\ US4STARP2 

US4STARP2 

US4STARP1 

te_type_cd 




OPTL 

^^^^^^^^^^^^ 

VREG 

STAX 

;taxablejnd 

Y 

Y 

Y 

Y 

Hpfc'l ' ' "SIS!* 

N 

N 

;inclusive_flg 

N 

N 

N 

N 

- - ■ N 

N 

N 

allocationjnd 

N 

N 

N 

N 

. -•■ . ■ N 

N 

N 

bac_acctjd 








dvr_dvrjd 

12345 

12345 

12345 

12345 


12345 

12345 

: rcc_chg _cat 

RNT 

RNT 

FUL 

SUR 


SUR 

VAT 


628 

628 

614 

445 


544 

753 

rcc_chg_seq 

1 

1 

12 

15 


15 

17 

l rct_chg_seq 

1 

8 

1 

2 


2 

1 

\ chg_st_dt 

200106040800 

200106040800 

200106040800 

200106040800 


200106040800 

200106040800 

chg_end_dt 

200106080800 

200106080800 

200106080800 

200106080800 


200106080800 

200106080800 


3.1.5.3.2 Vehicle Exchange 

A vehicle exchange can be made without necessarily calling the charge engine, unless there is a rate change or 
new documents/print-outs need to be generated for the customer. In that case, the client application has the 
option of passing the different rate structures along with the appropriate duration to the charge engine for 
calculation. Whether or not a call is placed, vehicle information must be retained so that the correct fuel 
calculation is made at closing. The next section shows the breakdown for a ticket where the vehicle was 
exchanged once. 
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3.1.5.4 Close Ticket 


When a vehicle is returned, the ticket is transitioned to the close status. At that time, all items that can 
generate a line item for this ticket should be known. If multiple vehicle movements took place during the 
rental, a repeating group of vehicle information must be passed to the charge engine so that the fuel 
calculation and associated surcharges for each vehicle can be generated. For the example shown below, 
assume that a vehicle exchange took place on 6/7 around noon. 
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4.1 Risks 

4.2 Assumptions 

4.2*1 Transaction Type 

1 . The transaction type is a pass-through variable for the surcharge engine and is intended to 
jy ; indicate whether the rental is a replacement or not. Its domain values are defined in the 
h Surcharge Engine design document 

O 

^.2.2 External Reference Data 

m 

1 . All required vehicle information required for surcharge calculations will be passed in by the 

a 1 client application, as fleet information will not be retained within the VRS database. 

w 

yi. VRS does not have direct access to the driver database table. Consequently, a renter ID must be 

kj provided with all requests. This ID is not validated and the user application may use anynon- 

jij zero number - that number can be the same for all transactions. 

m 
- 

C|3. No authorization data provided through iteration 3 (FNJBENGJSfUM^BIIXTO = 0 and 

B FN BENGJSRJM AUTH CHGS = 0). All charges are allocated to the renter. 

4.2.3 Rate Unit Type 

1 . Neither the PKG rate not the VAR rate structures will be used in Iteration 2 and Iteration 3 . 


4.2.4 Vehicle Exchange 

1 . During 'Open Ticket' and 'Close Ticket' state, each array of the rate structure should be 
duplicated for each vehicle exchange, but the actual rate parameters will be set to 0 or null for the 
second and all subsequent vehicles. This restriction is only for iteration 2. For iteration 3, rate 
information is required for each vehicle exchange f refer to section 3.1.4.2). 

2. When a vehicle exchange takes place with no rate changes, all surcharges pertaining to the car 
class or vehicle rates will be calculated against the first vehicle. Only refuel and associated 
percent-based surcharges and taxes will be calculated on the additional vehicles. In future 
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iterations (after the retrofit of the surcharge engine), the VLF will be calculated per day, per 
vehicle based on each vehicle movement - refer also to reworked example in section 3.1.5.4 and 
open issue #1 in section 4.3.4. 

3. Mileage calculation will accumulate across all vehicles used during the rental The charge will 
be calculated taking into consideration the total miles driven and the total free miles allowance. 
If the excess mileage rate is zero, a single line item for Unlimited Mileage will be created with a 
total charged amount of Q. 


4.2.5 Rate Optimization 

1 . When manual modification is made to a rate, whether it ! s the vehicle rate, equipment, ancillary 
items or coverage, there may be a requirement to optimize the unit counts. The charge engine 
always optimizes unless the client application instructs it not to. A single input flag is provided 
for that purpose (tn beng recalc unit flag> - See section 3.1.4 . 


For Weekend special products, it is expected that each of the three possible periods will be 
lit specified as a separate rate group (same product) and will be optimized independent of each other 
03 per ERAC's request. The rental duration for each period will be determined based on the start 
CJ and end date/time parameters. 


v 

5 8 

S'5 S 


4.2.6 Coverage Staggered Rates 


IJl . When the staggered number of days 'TN JBENG JNS JVBRJSTGJDAYS'' input parameter is 
111 non-zero, the staggered daily amount "FN_BENG_INS_STG_RT" must be populated. 


hi 

',17 - 


U2. When the staggered input parameters are specified, then the 'Per Week' and 'Per Month' 
^ parameters should not be populated. 

3. The threshold day parameter is used when and if optimization is required. 

4. The staggered rate applies to extra days beyond the initial days (threshold days). 

5. Although staggered rates will be used within NY state, the charge engine will not perform such 
validation, nor will it perform validation to ensure that staggered rates are specified for only PAI 
and PEC coverage types. 
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43 Issues 

43.1 Bundling 

1 . In VRS, when a component, such as equipment is bundled into the vehicle rate, all surcharges 
and taxes on that particular component, if they are also included, are added to the component's 
cost for unbundling purposes. Should the properties of the vehicle rate be used when calling for 
surcharges and taxes on inclusive components? 

RE: Yes, when an item is included, its surcharge and tax properties should be the same as the 
vehicle rate charge type. 

43.2 Coupon and Discount 

fJ l . The basis for discount and coupon is the remaining portion of the vehicle rate after the inclusive 

g components have been backed out. We need to verify whether this will match ECARS 

?j requirement. For example, if the vehicle charge is 100.00 and the sum of inclusive items is 

m 20.00, the remaining or effective vehicle charge is 80.00. Should a discount of 10% be off the 

m 100.00 or the 80.00? 
n 

SI RE: The discount is off the total rate before unbundling. In the above example, the 10% would 

W be applied against the 100.00. 


^433 Excess Mileage Rate 

1 . Does ERAC have a requirement for specifying excess mileage rate for each of the charge 

frequency buckets (Hourly, Daily, Weekly and Monthly) ? If such requirement exists, what are 
the guidelines for processing those charges ? 

RE: There is only one excess mileage rate. 



How should the charge engine handle customer satisfaction coupon in iteration 2 ? 


RE: John Evans will follow-up on this issue. 


m 
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4.3.4 Vehicle License Fee 

1. What are the Business rules to use in determining how vehicle surcharges are to be calculated ? 
Specifically, on a 3-day rental where the vehicle is exchanged with less than a full day remaining 
on the rental, how are 'perDay' or any other types of surcharges applied ? 

RE: This issue is still open and a follow-up with Paul Graves of ERAC on how this is currently 
handled today needs to occur. Section 3.1.4.2 describes a proposal for handling this issue and 
needs ERAC's approval. 

4.3.5 Tax and Surcharges 

1 . There is a requirement to waive surcharges and taxes at the transaction level. Specific taxes and 
surcharge types can be waived. One option under consideration is to allocate waived surcharges 
to a different payer (primarily an internal account if ERAC will still have to pay for it). 


32. Bundled charges - How do we handle tax on non-taxable items. How will the tax be actually 
paid ? Off tax charges or from revenue postings - Jon Jouris and John Evans will discuss with 
Pam. 


m 

m 

I!''™ 

w 

si 


ill 

|4 
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2.1,2.3 Use Case: User Creates Distribution Channel Rate Adjustment 


VRS will be enhanced to allow the user to define adjustments to established rates based on the distribution channel 
the renter used to initiate the reservation (Internet, GDS, Voice Reservations, etc.). A given rate adjustment entry 
will be specific to: 

Distribution Channel 

Product type 

Rate Hierarchy location (User defined area and type) 
Reservation date range 

For every rate adjustment entry, the user will provide a daily rate adjustment, and optionally a weekly rate 
adjustment, and monthly rate adjustment to be applied to the selected base rate. These adjustments can be either 
positive or negative, and may be expressed as either a fixed amount adjustment or a percentage adjustment. Rate 
adjustments will be factored into the rates returned by VRS and will not be broken out as a separate line item. 

When processing a reservation request, the rates engine will attempt to retrieve a distribution channel rates 
adjustment based on the input distribution channel, product type, reservation date, and rate hierarchy location that 
the associated rates header is defined at. If no entry is found for the above criteria, the rates engine will "work 
backward" through the distribution channel hierarchy searching for an applicable entry. 

The following example illustrates the concept of walking backward through the distribution channel hierarchy. 

Given: 

Travelocity is a child to Sabre in the distribution channel hierarchy 
Sabre is a child to GDS in the distribution channel hierarchy 
Retail rate is requested 

The rates engine is called, and the distribution channel code representing Travelocity is passed by the 
caller 

Result: 

The rates engine retrieves the appropriate retail rate header for the input pick up location 

The rates engine attempts to retrieve a rate adjustment for Travelocity based on the other inputs 

mentioned above. 

If no applicable entry is found for Travelocity, the rates engine attempts to retrieve an entry for Sabre 
If no applicable entry for Sabre is found, the rates engine attempts to retrieve an entry for GDS 


Goal In Context: 

Scope: 

Level: 

Pre-Condition: 

Success End Condition: 
Failed End Condition: 
Primary Actor: 

Trigger Event: 


Create the entries necessary to create rate adjustments for Retail 
products based on the channel used by the renter to reserve the vehicle. 
This Use Case deals with Create activity on the VRS distribution 
channel rate adjustment table. 

Distribution channels defined. Applicable product types created. User 
defined areas table populated with any necessary values. 
Distribution channel rate adjustment created 

Distribution channel rate adjustment entry not created successfully 

User responsible for maintaining distribution channel based rate 
adjustments (Super User). 

New distribution channel rate adjustment is created. 
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2.1.2.3.1 Main Success Scenarios 


There steps needed for creating are a distribution channel based rate adjustment are shown below: 
Step 1: User specifies distribution channel 

User specifies the distribution channel that the rate adjustment will be associated with. The distribution 
channel specified must be defined in an earlier process. 

Step 2: User specifies product type that the adjustment is being created for 

User chooses the product type that the adjustment applies to from a pick list that contains valid product 
types 

Step 3: User specifies valid start and end dates 

User provides the date range that the input distribution channel rate adjustment record will be valid for. 
Input effective start date must be greater than or equal to current date. Input effective end date must be 
greater than input effective start date. Suggest a default of current date (effective start date) and 3 1-DEC- 
2037 (effective end date). 

In order for a given row in this table to be selected, the reservation date and time passed by the caller to the 
rates engine must be between these two dates. No two rows in the distribution channel rate adjustments 
table can overlap on start and end dates for the same distribution channel, product type, location, and 
product type. 

Step 4: User specifies rate hierarchy location 

User provides user defined area name and type that the entry is applicable for. In order for this entry to be 
selected by the rates engine, the UDA name and type entered must match the UD A name and type from the 
candidate rate header. 

Step 5: User enters adjustment type 

The adjustment type indicates whether the amount provided represents a fixed amount or a percentage 
based adjustment. 

Step 6: User provides rate adjustment amount for daily rate 

The amount can be either positive or negative Percentage adjustments are entered as whole numbers. To 
reduce the selected rate by 10%, the amount would be entered as -10. 

Step 7: User provides rate adjustment amount for weekly rate 

The amount can be either positive or negative. The weekly adjustment amount is optional. Null value 
indicates no adjustment is applicable for weekly component 

Step 8: User provides rate adjustment amount for monthly rate 

The amount can be either positive or negative. The monthly adjustment amount is optional. Null value 
indicates no adjustment is applicable for monthly component 

Step 9: User saves record. 

Step 10: System validates input 

User interface verifies that no two rows "overlap" based on distribution channel, user defined area name 
and type, product type, and effective dates. System verifies that all data was entered, and valid values 
provided. Some sort of edit on the rate adjustment amounts would probably also be appropriate. Return 
error if invalid. 
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Step 11: New Unique Identifier is generated 

Retrieve next number to assign from Distribution channel rate adjustment table sequence generator. 
Step 12: System saves record 

The input record is written to the distribution channel rate adjustment table. 


b 


m 

las' 
hr4 


in 


Column Description 

Data Type 

Remarks 




DCRAUniq Identifier 

Number(15) 

Sequence Number 

Distribution Channel 

Varchar2(12) 


User Defined Area ID 

Varchar2(10) 


User Defined Area Type 

Varchar2(10) 


Product Type 

Varchar2(l) 


Effective Start Date 

Date 


Effective End Date 

Date 


Adjustment Type 

Varchar2(l) 

<A>mount or <P>ercentage 

Daily Adjustment 

Number(15,3) 


Weekly Adjustment 

Number(15,3) 


Monthly Adjustment 

Number(15,3) 



2.1.2.3.1.1 Scenario 1: User creates new distribution channel rate adjustment 


The following data is provided by a user to create a distribution channel rate adjustment entry: 


Distribution Channel: 
Product Type: 
Effective Start Date: 
Effective End Date: 
Rate Hierarchy Location: 
Daily adjustment: 
Weekly adjustment: 
Monthly adjustment: 


Internet 
R 

01-SEP-2001 
Ongoing 
Branch 0110 
10% off 
10% off 
5% off 


The goal is to provide a discount off of retail rates for renters using the Enterprise web site for making 
reservations. The daily and weekly rates for any applicable retail products will be reduced by 10%. The 
monthly rate will be reduced by 5%. The rate adjustment is valid for all car classes for reservations made 
on or after September 1, 2001. This offer is only good for rentals picked up at branch 0109. 
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INTERNET 


Internet Channel 


R 


Standard Retail Rates 


User selects distribution channel INTERNET from pick list 
User specifies rate adjustment applies to retail rates 


0110 

T 

ATYJBRANCH 

T 


User selects user defined area defining geographical scope of the new row (Group 01). 


01-SEP-2001 


31-DEC-2037 


Percent 


User Sets Start date to September 1, 2001 

User accepts default end date 

User selects rate adjustment type (Percent) 


-10 


-10 


-5 


m 

m 

s . 

Saras 


User sets daily, weekly, and monthly rate adjustment amounts and types 

User saves record 
System validates user input 
System writes new record 


The following record represents a row in the distribution channel rate adjustment table. This entry will be 
applied to any retail products that are defined at branch 01 10. 


Unique 
Identifier 

Distribution 
Channel 

Product 
Type 

Uda Area ID 

Uda Aty Area 
Type 

Effc Start 
Date 

Effc End 
Date 

0000000001 

Internet 

R 

0110 

ATY Branch 

01-SEP-2001 

31-DEC-2037 


Adjustment 
Type 

Daily 

Adjustment 
Amount 

Weekly 

Adjustment 

Amount 

Monthly 

Adjustment 

Amount 

P 

-10 

-10 

-5 
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2.1.2.3.1.2 Scenario 2: User creates new distribution channel rate adjustment for Retail at Region 01 A 


The following data is provided by a user to create a distribution channel rate adjustment entry: 


pi 

; 5 


Distribution Channel: 
Product Type: 
Rate Hierarchy Location: 
Effective Start Date: 
Effective End Date: 
Daily adjustment: 
Weekly adjustment: 
Monthly adjustment: 


Sabre 
R 

Region 01 A 
01-SEP-2001 
Ongoing 
10% off 
Not Provided 
Not Provided 


The goal is to provide a discount off of retail rates for renters using Sabre to make a reservation. The daily 
rates for any applicable retail products will be reduced by 10%. Since no weekly or monthly adjustment was 
provided, and weekly or monthly rate components returned by the rates or billing engine will not be 
adjusted. The rate adjustment is valid for all car classes for reservations made on or after September 1, 
2001 . This offer is only good for rentals where a retail product defined for Region 01 A was selected by the 
rates engine. 


Sabre 


Sabre 


R 


Standard Retail Rates 


jpss 

Hi 
ill 

m 


User selects distribution channel Sabre from list of valid distribution channels 
User specifies rate adjustment applies to retail rates 


01A 

T 

ATY_REGION 

T 


User selects user defined area defining geographical scope of the new row (Group 01). 


01-SEP-2001 


31-DEC-2037 


Percent 


User Sets Start date to September 1 , 200 1 

User accepts default end date 

User selects rate adjustment type (Percent) 


-10 


NULL 


NULL 


User sets daily rate adjustment amount. No weekly or monthly is given 

User saves record 
System validates user input 
System writes new record 
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The following record represents a row in the distribution channel rate adjustment table. This entry will be 
applied to any retail products that are defined at region 01 A. 


Unique 
Identifier 

Distribution 
Channel 

Product 
Type 

Uda Area ID 

Uda Aty Area 
Type 

Effc Start 
Date 

Effc End 
Date 

0000000001 

Internet 

R 

0110 

ATY_ BRANCH 

01-SEP-2001 

31-DEC-2037 

0000000002 

Sabre 

R 

01A 

ATY REGION 

01-SEP-2001 

31-DEC-2037 


Adjustment 
Type 

Daily 

Adjustment 
Amount 

Weekly 

Adjustment 

Amount 

Monthly 

Adjustment 

Amount 

P 

-10 

-10 

-5 

P 

-10 




* Row in bold represents new data added for scenario 2 


2.1.2.3.2 Scenario Extensions 

2.1.2.3.3 Scenario Variations 

2.1.2.3.3.1 User Updates Distribution Channel Rate Adjustment Entry 

The only information that can be updated for an existing record is the effective end date. The 
distribution channel rate adjustment record is invalid after the effective end date. The effective end 
date may be set to any valid date that is less than the existing effective end date and not less than the 
greater of either the effective start date or the current date. 

2.1.2.3.3.2 User Deletes a Distribution Channel Rate Adjustment entry 

A user does not have the ability to physically delete an existing record. 

2.1.2.3.4 Related Information 
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2.1.2.3.5 Appendix A - Distribution Channel Rate Adjustment Retrieval 

After a product/location offering (rates header) is selected by the rates engine, the distribution channel rate 
adjustments table is searched for any adjustments that apply to the selected product/pick up location. The 
distribution channel rate adjustment table is searched , looking for 

An entry where the distribution channel matches the input distribution channel or one of it's parents in the 

distribution channel hierarchy and 

The location (user defined area ID and type) for the distribution channel rate adjustment entry is equal to the 
user defined area name and type from the selected rate header. 

The figures below illustrate this concept: 

Assume: 

Distribution channel Travelocity is a child of distribution channel Sabre 
Distribution channel Sabre is a child of distribution channel GDS 

A reservation request is received through distribution channel Travelocity for a retail product to be picked up at 
branch 0110 

The retail rate for branch 0 1 1 0 is set up at the region level (Region 0 1 A) 
Distribution channel rate adjustment table as shown below: 


Unique 
Identifier 

Distribution 
Channel 

Product 
Type 

Uda Area ID 

Uda Aty Area 
Type 

Effc Start 
Date 

Effc End 
Date 

0000000001 

Internet 

R 

0110 

ATY BRANCH 

01-SEP-2001 

31-DEC-2037 

0000000002 

Sabre 

R 

01A 

ATY REGION 

01-SEP-2001 

31-DEC-2037 


Adjustment 
Type 

Daily 

Adjustment 
Amount 

Weekly 

Adjustment 

Amount 

Monthly 

Adjustment 

Amount 

P 

-10 

-10 

-5 

P 

-10 
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Given the above scenario, the distribution channel rate adjustment table would be searched as shown in the following 
diagram: 


jjssss 


IV 

I.S 




Look for match w/dist 
channel = Travelocity 
and Product Type = R 
and Region = 01A 


Look for match w/dist 
chaimel = Sabre 
and Product Type = R 
and Region = 01 A 


No 

Match 



Match found on dist channel Sabre - 
and rate hierarchy location - Region 
01 A. Discontinue search and return 
daily rate adjustment of -10%. 


W 

1+ 
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2.L2.4 Use Case: User Creates Rate Detail 

The rate detail component describes the rate amounts and mileage limits for a single car class, reservation date range, 
and pickup date range for a specific rate header. Distance limits (the distance unit depends on the country where the 
rate is defined) and an excess distance charge can optionally be provided at the rate detail level. At minimum, there 
will be one rate detail for every car class offered by a rate header. 

There are presently three types of rate detail in the VRS system. The time and mileage rate type extends some 
combination of hourly, daily, weekly, monthly, extra day and extra hour rates. The variable rate allows a different 
rate amount to be specified for each day of the week. The package rate varies the rate amount based on the length of 
the rental SI retail and weekend special products will use the standard time and mileage rate type. 

A fourth rate type is being introduced to VRS for Iteration Three. This rate type is a variant of the existing VRS 
package rate and will be used to store Bid Price rates, 

jU The VRS Bid Price rate detail will be created by the NatRes to VRS data bridge. The existing NatRes system 

O provides a Bid Price create/update user interface which among other things, keeps the rates stored in NatRes 

f\ synchronized with the corresponding rates displayed on the GPS'. Any new user interface accessing the Bid Price 

m rates stored in VRS should access the bid price rates for DISPLAY only. No create/update is permitted . 

Create the rate detail for a standard SI retail product. Create rate detail 
for a weekend special product. When tihe task is complete, the 
appropriate data will be added to the RATE_DETAILS table. 
This Use Case deals with Create activity on the VRS rate detail table 
(RATE_DETAILS). 

Rate header record created and applicable rate qual attached 

Rate detail record created. 

Rate detail record not created successfully 

User responsible for maintaining rate and mileage data. 
Rate bridges from ERAC system to VRS 
New rate detail is created. 


There are several steps involved in creating rate detail for use by SI retail (Non Bid Price) and special 
products . 

Step 1: User selects rate header to add/update rate detail for 

User specifies the appropriate rate header from a list of valid domain values. This list can be scoped by 
product type (i.e. <R>etail), and location. 

Step 2: User enters date (optionally time) that rate will first be available for reservation 

Date must be current or future. If current date is entered, time is defaulted to current time. If date is future, 
default to 00:00:00. Time portion should be stored in hh24:mi:ss format. 

Step 3: User enters date (optionally time) that rate will last be available for reservation 

Date must be current or future and greater than reservation start date. If current date is entered, time is 
defaulted to current time. If date is future, default to 23:59:59. Time portion should be stored in hh24:mi:ss 
format. 


Goal In Context: 


Sis £ 


m 

as. 

5 s 


Scope: 
Level: 

Pre-Condition: 


P Success End Condition: 

U3K. 

Failed End Condition: 
Primary Actor: 

Trigger Event: 
2.1.2 AA Main Success Scenarios 
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Step 4: User enters date (optionally time) that rate will first be available for rental 

Date must be current or future. If current date is entered, time is defaulted to current time. If date is future, 
default to 00:00:00. Time portion should be stored in hh24:mi:ss format. Rental start date cannot be less 
than reservation start date. 

Step 5: User enters date (optionally time) that rate will last be available for rental 

Date must be current or future and greater than rental start date. If current date is entered, time is defaulted 
to current time. Time portion should be stored in hh24:mi:ss format. If date is future, default to 23:59:59. 
Rental end date cannot be less than reservation end date. 

Data maintenance process could optionally present one set of dates when rates are being input 
Reservation start and end dates could be set to the same values as rental start and end dates. 

Step 6: User enters car class and car class suffix rate is applicable for 

Data maintenance process verifies valid car class and suffix entered. If car class invalid, return error 
message and halt processing. 

Step 7: User enters hourly rate 

Hourly rate is optional Will not be entered for Special rates. 
Step 8: User enters hourly distance limit (if applicable) 

Optional. Required if hourly rate is present and daily mileage limit specifie d. Will not be entered for 
Special rates. 

Step 9: User enters daily rate 
Daily rate is required 

Step 10: User enters daily distance limit (if applicable) 

Optional. If daily mileage limit is omitted, unlimited mileage is implied. 

Step 11: User enters weekly rate (if applicable) 

Weekly rate not required. Will not be entered for Special rates. 

Step 12: User enters weekly distance limit (if applicable) 

Weekly mileage is required if weekly rate entered and daily mileage limit specified 

Step 13: User enters monthly rate (if applicable) 

Monthly rate not required. Will not be entered for Special rates. 

Step 14: User enters monthly distance limit (if applicable) 

Monthly mileage is required if monthly rate entered and daily mileage limit specified 

Step 15: User enters extra day rate (if applicable) 

Not used at this time 

Step 16: User enters excess mileage amount (if applicable) 

Must be entered if mileage limits specified 

Step 17: User attempts to save record 


Step 18: Data maintenance process retrieves rate detail sequence number 


Last Save Date:l 1/5/2001 10:18 AM 


Page 66 of 114 


Consolidated Products and Rates Design J3 


Data name on data record for sequence number is rtd_id 

Step 19: Data maintenance process ties rate detail record to associated rate header 

The data maintenance process places the unique identifier of the associated rate header record 
(rthjiniq_id) into the foreign key field of the new rate detail record (rh_rth_uni<Ljd). 

Step 20: Data maintenance process performs "authorization process" for rate detail record 

Authorization process includes: 

Performing edits based on steps 2 through 1 5 

Any other edits Enterprise feels are necessary to ensure valid rates 

If errors are detected in the authorization process, the rate detail rate authorization flag (column name 
auth_flg) is set to "IF (Unauthorized). If no errors are detected, the rate authorization status is set to "A" 
(Authorized). In either case, the data maintenance process inserts the creation operator id in the 
authorization user field (column name authjisr _id), and the current date/time in the authorization date field 
(column name auth dt). The VRS rates engine will not use any rate detail records that are 
unauthorized (auth_flg not equal to "A"). 

Step 21: Data maintenance process inserts new row into rate details table 

CREATJDPERJD field is populated with the ID of the user who created the new record. CREATEDT 
field is set to current date and time. RTDJTYPE field is set to 'TM' (indicating that the rate detail is a time 
and mileage type rate). 

If authorization errors are encountered (auth_flg not equal to "A"), a list of errors should be returned the 
user. The user can be given the opportunity to correct the errors and retry rate authorization, or the user can 
save the unauthorized record, and return at a later time to correct and authorize the rate detail record in 
error. 

If the authorization process is successful, the record is written to the database and committed. 
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rent-a-car 
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Q 

s - s 


o 

I 5 


Column Descrintinn 

V^UiUmu lNaluc 

Data lype 

Rate Detail Seauence Number 

XvlU. 1U 

iNUmoer^i j) 

uwning Kate rieaaer unique laentitier 

Rhjrth_uniq_id 

Number(15) 

Rate Detail Type 

Rtdjype 

Varchar2(10) 

Car Class 


Varchar2(8) 

Car Class Suffix 


Varchar2(4) 

Reservation Start and Time _ 

Res strt dt 

Date 

Reservation End and Time 

Res end dt 

Date 

Rental Start and Time 

Co strt dt 

Date 

Rental End and Time 

Co end dt 

Date 

Hourly Rate 

Hr amt 

Number(15,3) 

Hourly Mileage Limit 

Hr mil nbr 

Number(4) 

Daily Rate 

Dly amt 

Number(15,3) 

Daily Mileage Limit 

Dly mil nbr 

Number(4) 

Weekly Rate 

Wk amt 

Number(15,3) 

Weekly Mileage Limit 

Wk mil nbr 

Number(4) 

Monthly Rate 

Mth amt 

Number(15,3) 

Monthly Mileage Limit 

Mth mil nbr 

Number(4) 

Number of Days in Rental Month 

Mth factor nbr 

Number(2) 

Excess Mileage Amount 

Excess mil amt 

Number(15,3) 

Authorization Operator 

Auth usr id 

Varchar2(32) 

Authorization Date 

Auth dt 

Date 

Authorization Status 

Auth fig 

Varchar2(l) 

Create Operator 

Creat oper id 

Varchar2(32) 

Create Date 

Create dt 

Date 

Update Operator 

Updt oper id 

Varchar2(32) 

Update Date 

Updt dt 

Date 


Other data columns available on the rate details table will be introduced in future iterations 
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rent-a-car 


perotsystems- 


III 

01 


2.1.2.4.1.1 Scenario 1 : User creates new rate detail record for SI retail rate header 
The following data is provided by a user to create an SI retail rate detail: 


Product: 
Location: 
Current Date: 

Car Class: 
Res Start: 
Res End: 
Rental Start: 
Rental End: 

Daily Rate: 
Daily Mileage Limit: 
Weekly Rate: 
Weekly Mileage Limit: 


Limited Mileage Medium Free Mileage 

Branch 0109 

01-JUN-2001 

CCAR 

01-JUN-2001 

31-AUG-2001 

01-JTJN-2001 

31-AUG-2001 

17.99 
150 
108.95 
900 


Excess Mileage Charge: .25/mile 


R 


Standard Retail Rates 


0109 

T 

Branch 

T 


The user might begin by using a pick list in order to view all retail rate headers set up at branch 0109 


LIMMED 

Retail - 150 Free Miles/Day 

UNLIMITD 

Retail - Unlimited Free miles 


The pick list might reveal feat there are currently rate headers for two retail products available at branch 0109. The 
user selects the product (LIMMED) whose rate header describes it as a limited miles retail product The user enters 
the data shown above and the results are shown on the following page . 
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2. 1.2.4. 12 Scenario 2: User creates new rate detail record for SI special rate header 


The following data is provided by a user to create an SI weekend special rate detail: 


Product: 

WSLMRT 

Location: 

Branch 0109 

Current Date: 

01-JUN-2001 

Car Class: 

CCAR 

Res Start: 

01-JUN-2001 

Res End: 

31-AUG-2001 

Rental Start: 

01-JUN-2001 

Rental End: 

31-AUG-2001 

Special Rate: 

9.95 


n 
m 

iii 


hp 


Special Rates 


0109 

T 

ATYBRANCH 

T 


The user might begin by using a list of valid domain values in order to view all retail rate headers set up at branch 
0109 


WSLMRT 


Weekend Special Branch 0109 


ill 


The pick list might reveal that there is currently a rate headers for a weekend special product available at branch 
0109. The user selects the product (WSLMRT) whose rate header describes it as a weekend special at branch 0109. 
The user enters the data shown above and the results are shown on the following page . 
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2.1.2.4.1.3 Scenario 3 : User views Bid Price rate detail at branch QUO 

The user wishes to view a rate at branch 0110 (UM). The following data is provided by a user to 
view a VRS Bid Price rate: 


R 


Standard Retail Rates 


0110 

T 

ATY_BRANCH 

T 


The user might begin by using a list of valid domain values in order to view all retail rate headers set up at branch 
0110 


BIDRTL 


Bid Price Rate Branch 01 10 


cs 

fin 
Si 


The pick list might reveal that there is currently a rate header for a single retail product available at branch 0110. 
The user selects the product (BIDRTL) whose rate header describes it as a Bid Price Rate at branch 01 10. The rate 
base unit on this rate header will contain the value "B'\ This will indicate that the data elements populated on any 
associated rate headers will be the following: 


m 


Column Description 

Column Name 

Data Type 

Rate Detail Sequence Number 

Rtdjd 

Number(15) 

"Owning" Rate Header Unique Identifier 

Rh_rth_uniq_id 

Number(15) 

Rate Detail Type 

Rtdjype 

Varchar2(10) 

Car Class 


Varchar2(8) 

Car Class Suffix 


Varchar2(4) 

Reservation Start and Time 

Res strt dt 

Date 

Reservation End and Time 

Res end dt 

Date 

Rental Start and Time 

Co strt dt 

Date 

Rental End and Time 

Co end dt 

Date 

Base Days 

Base days 

Number(3) 

Base Rate 

Base it 

Number(15,3) 

Base Plus 1 Day Amount 

Plusl amt 

Number(15,3) 

Base Plus 2 Days Amount 

Plus2 amt 

Number(15 5 3) 

Base Plus 3 Days Amount 

Plus3 amt 

Number(15,3) 

Weekly Rate 

Wk amt 

Number(15,3) 

Monthly Rate 

Mth amt 

Number(15,3) 

Monthly Mileage Limit 

Mth mil nbr 

Number(4) 

Number of Days in Rental Month 

Mth factor nbr 

Number(2) 

Authorization Operator 

Auth usr id 

Varchar2(32) 

Authorization Date 

Auth dt 

Date 

Authorization Status 

Auth fig 

Varchar2(l) 

Create Operator 

Creat oper id 

Varchar2(32) 

Create Date 

Create dt 

Date 

Update Operator 

Updt oper id 

Varchar2(32) 

Update Date 

Updt dt 

Date 


* Other data columns available on the rate details table will be introduced in future iterations 
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The resulting display will show the one, two, three, and four day rates for the selected rate header 
as well as the weekly and monthly rates. The NatRes Active Rate (Bid Price) to VRS Bid Price 
data mapping is shown below. 


Given the following ERAC Active (Bid Price) Rate: 


Car Class: 

ICAR 

One Day Rental Daily Rate: 

$23.00 

Two Day Rental Daily Rate: 

$22.00 

Three Day Rental Daily Rate: 

$22.00 

Four Day Rental Daily Rate: 

$21.00 

Weekly Rate: 

$105.00 

Monthly Rate: 

$420.00 

VRS Bid Price Equivalent (Using Package Rate Data Elements) 

Vehicle Category: 

ICAR 

Base Days: 

1 

Base Rate: 

$23.00 

Plus 1 Amount: 

$22.00 

Plus 2 Amount: 

$22.00 

Plus 3 Amount: 

$21.00 

Weekly Rate: 

$105.00 

Monthly Rate: 

$420.00 


ERAC Bid Price Column 

Corresponding VRS Bid Price Column 

Remarks 




Car Type 

Vet cat cd 


Day rental price 1 

Base rt 


N/A 

Base_days 

Will always be = 1 for Bid Price 

rates 

Day rental price 2 

Plusl amt 


Day rental price 3 

Plus2 amt 


Day rental price 4 

Plus3 amt 


Weekly rental price 

Wk amt 


Monthly rental price 

Mth amt 
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2.1.2.4.2 


Scenario Extensions 


2.1.2.4.3 


Scenario Variations 


2.L2.4.3.1 


User Updates the Rate Detail Record 


2.1.2.4.3.1.1 Unauthorized Rate Detail 


For an unauthorized rate detail record, most data fields that allow user input during record creation 
time can be updated. When the user attempts to save the updated unauthorized rate detail record, 
the authorization process is repeated. 


For an authorized rate detail record, the only field available for update is the reservation end date. 
The reservation end date of the rate detail record represents the last date and time that a 
reservation may be taken for the particular rate. The reservation end date can be updated to: 

Any valid date that is less than the current value of reservation end date.(Reservation end date 
cannot be extended) 

Any valid date that is greater than or equal to the current date (Reservation end date cannot be 
back-dated). 

If the reservation end date is set to the current date, the time portion is set to current time. If the 
reservation end date is set to a future date, the time portion is set to 23:59:59. End dating a rate 
detail is one way of stopping a rate from being offered in the future. 


Unauthorized rate detail records can be physically deleted A user does not have the ability to 
physically delete an authorized rate detail record. 


2. 1.2. 4. 3. 1.2 Authorized Rate Detail 


2.1.2.4.3.2 User Deletes a Rate Detail 


2.1.2.4.4 


Related Information 


2.1.2.4.5 


References/Appendix -A 
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2.1.2.5 Rate Header Qualification Association 
2.1.2.5.1 Characteristic Information 

VRS rate qualifications (rate qual) describe what conditions need to be met in order to qualify for a product at a 
particular location. Rate qualification records cannot be altered. 

For any given reservation date/time and rental date/time combination, there can only be one applicable rate qual 
associated to the rate header. (Only one rate qual can be actively associated to a rate header at any one point in 
time). The initial rate header qual association is established when the rate header is created. For most products, this 
rate header/rate qual relationship may never require any maintenance. The rate header qual association table 
(RATE_HEADER_QUAL_ASSN) allows the user to associate a different qual with a rate header if business 
conditions warrant. This use case will illustrate how to associate a different rate qual to a given rate header. 

Goal In Context: ERAC user associates a different rate qual with a rate header. Existing 

rate header qual association record updated and new rate header qual 
association record populated with appropriate data and new data record 
stored in VRS database. 

Scope: This Use Case deals with the Create activity on the VRS rate header qual 

association table. (RATEJHKADER_QUAL_ASSN). 

Level: 

Pre-Condition: Rate header previously defined and original rate header qual association 

in place. Appropriate rate quals have been created. 

Success End Condition: Different rate qual associated with a rate header. Existing rate header 

qual association end dated and new header qual record properly created. 

Failed End Condition: Different rate qual not associated with rate header. No data updates or 

creation takes place. 

Primary Actor: User responsible for maintaining qualification rules for a product at a 

given location. 

Trigger Event: Different qual associated to a rate header 


2.1.2.5.2 Main Success Scenarios 

The following steps detail the process of associating a different qual to a rates header: 
Step 1: User selects rate header that requires new qual association 

User specifies the appropriate rate header from a pick list. This pick list can be scoped by product type (i.e. 
<S>pecial), and location. 

Step 2: Data maintenance process defaults reservation start date and time to current date and time 

Time portion should be stored in hh24:mi:ss format. 

Step 3: : Data maintenance process defaults reservation end date and time to reservation end date and time of 
current active row. 

Time portion should be stored in hh24:mi:ss format 

Step 4: : Data maintenance process defaults rental start date and time to reservation start date and time of 
new record. 

Time portion should be stored in hh24:mi:ss format. 
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Step 4: : Data maintenance process defaults rental end date and time to reservation end date and time of new 
record. 

Time portion should be stored in hh24:mi:ss format. 

Step 5: User selects new rate qual for this product offering 

User selects rate qual from pick list. The value to be stored is an integer. The pick list should display the textual 
description of the quals. The data maintenance process will verify that a valid qual is entered or selected. 

Step 6: User attempts to save the new record. 

Step 7: The data maintenance process updates the reservation end date of the existing active rate header qual 
association record. 

Reservation end date of existing active rate header qual assn. row is set to reservation start date/time of new row 
minus one second. 

Step 8: The data maintenance process formats rate header qual association row 
(RATEJHEADER_QUAL_ASSN) 

Retrieve RATEJHEADERJ3UALASSN sequence number from rate header qual association sequence number 
generator 

Format the new row as follows: 


Rate Header Qual Assn Column 

Source 

RHQA UNIQ ID 

Generated sequence number 

RH RTH UNIQ ID 

RTH UNIQ ID from rate header 

RDB DRTN BND CD 

Value selected from rate qual pick list 

RES START DT 

Current date and time 

RES_END_DT 

Reservation end date and time of existing 
active record (This value was retrieved and 
saved prior to updating the reservation end 
date of the existing active record. . 

EFFC_STARTDT 

Reservation start date and time of new 
record. 

EFFCJENDJ3T 

Reservation end date and time of new 
record. 

CREATE OPER 

ID of operator performing create 

CREATE DT 

Current system date/time 


RES and EFFC start and end dates will contain both the date and time w/time in hours, minutes, and seconds. 

Step 9: The data maintenance process inserts rate header qual association row into rate header qual 
association table (RATE JffiEADERJJUAL_ASSlS). 

Step 10: Upon successful update of the existing row, and insertion of the new row in the rate header qual 
association table (RATEJHEADER_QUAL_ASSN), the data maintenance process issues commit If either the 
insert or update fails, data maintenance process issues a rollback. 
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2.1.2.5.2.1 Scenario 1: Associates Different Oual to a Weekend Special Product 
Given: 


The weekend special product at branch 0109 is currently using a rate qual (qual ID 000002) that allows pick up on 
Thursday at noon. The business has decided that the weekend special should be available on Friday morning for pick 
up as early as 8:00 a.m. A rate qual supporting the new requirement has been created. 

The new qual is associated to the rate header at 2:15 p.m. on June 01, 2001 . 


User Input: 


Special Rates 


0109 

T 

ATYBRANCH 

T 


WEEKEND 


Weekend Special - Unlimited Miles 


User selects product/location from pick list. Data maintenance process retrieves associated rate header and saves the 
unique identifier of the rate header (rth_uniq_id) for later use. 


000002 

Weekend Special Noon Thurs Pickup 

T 

000003 

Weekend Special S a.m. Friday Pickup 



User selects new rate qual from pick list. Two weekend type quals are available; user selects qual with Friday 8:00 
a.m. pickup. 

User attempts to save new rate header qual association 
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2.1.2.5.3Scenario Variations 


2.1.2.5.3.1 User Updates Rate Header Oual Association Entry 


No manual updates to the rate header qual association are permitted. Any updates are handled by the data 
maintenance form that creates a new association record. 


Last Save Date:l 1/5/2001 10:18 AM 


Page 81 of 114 


Consolidated Products and Rates Design_I3 



3.1 Rate Engine 

The VRS Rate Engine is a series of programs / services that apply business-defined rules, based on pricing related 
data, to facilitate the retrieval of rates and related rules for various components that drive the reservation and rental 
transactions. 

Two new rate engine services would be required for ERAC's retail business. The Applicable Product Service (APS) 
would be responsible for determining the list of applicable products for a given set of input criteria. The list of 
applicable products would be presented by the graphical user interface. The rental employee would make a selection 
from the list and the Product Rate Service (PRS) would be invoked. The PRS would be responsible for determining 
the appropriate rate for the selected product. If the APS would return a list that contains only one product, no user 
intervention would be required, and PRS could be immediately invoked with the single product 

3.1.1 Applicable Product Service - APS 

This service module determines the list of applicable products for the given set of input criteria. The APS is invoked 
by the client application to generate the list of applicable products eligible to offer to the rental customer. 
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3.1.1.1 Inputs 


Applicable Product ServM^IPI^^ 



oource ot 

Input Paramete&m 

III i. 





Size 

Standard Header 

The content of this header will be 

u^Pfl fnr riphunninn n^prte^t 
uocu iui ucuuyyiiiy, uoci iCoL 

support, performance monitoring, 
tuning and error logging 

refer to standard header 
aocumeni ror layout ana 
population rules 

Mandatory 




Client App 

view version 

TUX interface id string 

FNJWRENGTV001 VERSION 

Mandatory 


string 

100 

Tux View 

rate source 

Rate Source 

FN_MEN RATE SOURCE 

Mandatory 


string 

3 

Client App 

res stn id 

Reservation Station ID (Branch) 

FNJWEN RES STN ID 

Mandatory 


string 

11 

Client App 

resjmsp 

Reservation timestamp 

FN_MEN RES TMSP 

Mandatory 


string 

13 

Client App 

co stn id 

Pick-up Station ID (Branch) 

FN_MEN_CO STN ID 

Mandatory 


string 

11 

Client App 

co_cty 

Pick-up country 

FNJVIEN CO CTY 

Mandatory 


string 

4 

Client App 

cojmsp 

Pick-up timestamp 

FN MEN CO TMSP 

Mandatory 


string 

13 

Client App 

cijmsp 

Return timestamp 

FN_MEN_CI TMSP 

Mandatory 


string 

13 

Client App 

primary_only 

Request Primary product only 

FN^MEN_PRIMARY ONLY 

mS 

N 

mm 


Client App 


m 

Si 

III 


01 

M 
lA 





k^,fS£M£P SIS 

standard header 


view version 

System generated 

rate_source 

R 

res stn id 

0109 

resjmsp 

200107211315 

co stn id 

0109 

co_cty 

US 

cojmsp 

200107211315 

cijmsp 

200107221315 

cijatnjd 

0109 

cijmsp 

200107221315 

primary only 

N 
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3.1.1.2 Outputs 


Applicable pro<^m^0pmm^^^^^^^m 




mm mWw 


- 







^^^^ 



engine_error 

Server error Code or 0 


U 

long 

4 

APS 

enqine messaae 

Server Error Text 

r in iwiCiN cr\r\_ IVltooAo t 

An OK 

string 

100 

APS 

areajds 

For internal use bv the Rate Fnninp anri 
Sub-engines 

FN MFM AREA IRQ 

1 0109 , BRA 

NCHT0137 

REGION'! 

string 

1000 

APS 

n u m_ap pijD ro as 

Number of applicable products made up 
of below components (1-25) 

FN_MEN_REC_COUNT 

1 

iong 

4 

APS 

rate_header_key 

Rate Header Unique Identifier 

FNJ/IENJRATEJHDRJD 

9 


4 

RTH 

uda 

UDA where the Rate Header is defined 

FNJVIENRTHJJDA 

0109 

strina 

11 

RTH 

r\ i n 

udajype 

UDA Type for the UDA 

FNJWENJRTH_UDA_TYPE 

BRANCH 

string 

11 

DTU 

r\ i n 

description 

Rate Header description 

FNJV!EN_RTH_DESC 

UNLIMITED 

string 

36 

DTU 

priigtry_rate_jnd 

Primary Rate Indicator 

FN_MEN_PR1M_RATEJND 

P 

char 

1 

RTH 

prqpnsLcd 

Product Instance Code 

FNJVIENPRODJNST_CD 

UNLIM 

string 

9 

K t n 

prd&ffamily 

Product Family 

FNJvlEN_PROD_FMLY 

RUNL 

string 

5 

RTH 

prcK$Sct_type 

Product Type 

FNJWE N_PROD_TYP_CD 

R 

char 

1 

RTH 

curlency^cd 

Currency Code 

FNJVlEN_CURR_CD 

USD 

string 

4 

RTH 

ratey>ase_unit 

Rate Base Unit 

FN JvlEN_RATE_BASE_UN IT 

D 

char 

1 

RTH 

taxjJficfuded 

Tax Included 

FNJVENJTAXJNCL 

N 

char 

1 

RTH 

surbhargejncluded 

Surcharges Included 

FNJMEN_SCHG_I NCL 

N 

char 

1 

RTH 

fuef Included 


Fuel Included 

FN JVIEN^FU ELJ NCL 

N 

char 

1 

RTH 

discountable 

Discountable 'Y' or 'N' 

FN_MEN_DSCNT_FLG 

Y 

char 

1 

RTH 

blllMi cycle 
i ^ 1 

24-hour(H) OR Calendar Day(C) 

FN_MEN_BILLING_CYCLE 

H 

char 

1 

RTH 
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3.1.1.3 Detailed Process Flow 

Once a user's request has been transmitted through the Tuxedo interface, the APS begins its task of generating the list 
of applicable products. 


Receive and Validate 
Inputs 


Determine 
UDAs 



Reservation DateTime 
CheekOut bateTime 
CheekOutUMs 


Retrieve 
Applicable 
Products 


Check 
Reservation 
Applicability 
for each 
Applicable 
Product 


Distribution Channel 


Reservation OateTime 


Populate 
Outputs 


The APS will validate that the Reservation DateTime, Pick-up DateTime, and Return DateTime are valid. The valid 
format for input dates is YYYYMMDDHH24MI. For example, 200107211315 would represent July 21, 2001 
1:15pm. 

The Return DateTime must be later than the Pick-up DateTime. 

If the input dates fail the validation checks, the APS will return an error to its caller along with a message indicating 
"Invalid Dates". 

The APS will determine the list of UDAs and UDA-Types to which the Pick-up Branch belongs. The method in 
which the list of UDAs is determined is detailed in the UDA Hierarchy Design Document. This list will be used when 
determining the list of applicable rate headers. 

If the list of UDAs is empty, the APS will return an error to its caller along with a message indicating "Data setup 
error - Pick-up Branch / UDA inconsistency". 

The APS will use the Reservation DateTime, Pick-up DateTime, Rate Source and the list of UDAs and UDA-Types to 
determine the list of applicable rate headers. 

The following constraints will be used when querying the RATES_HEADER table: 
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KATES HEADER 


Reservation DateTime BETWEEN RTH.EFFC_START_DT and RTH . EFFC_END_DT 

Rate Source « RTH . PROD_TYPE_CD 

RTH . UDA_ATY_AREA_TYP in (UDA-Types List) 

RTH.UDAJVREAJED in (UDAs List) 

The APS will maintain the results of the query in a linked list of applicable products. 

The linked list will be traversed to retain entries which are defined at the lowest level in the Pick-up Branch's rate 
hierarchy. For example, if the list contains an entry which has a UDA-Type of BRANCH, then all other entries which 
do not have a UDA-Type of BRANCH will be removed from the linked list 

If the PrimaryOnly input value is set to Y, then only the rate header which has the PRIM_RATE_IND set to T' 
(designated as being PRIMARY) at the lowest level in the Pick-up Branch's rate hierarchy will remain applicable, and 
all other entries will be removed from the linked list. 

For each remaining entry in the linked list of applicable products, the reservation applicability will be checked by 
querying the PROD_AVLS table. 

The following constraints will be used when querying the reservation applicability table: 

AVL PROD_AVLS 

Reservation DateTime BETWEEN AVL.EFFC_START_DT and AVL.EFFC_END_DT 
Product Code from Rates Header = AVL.PRC_PROD_INST_CD 
Distribution Channel = AVL . DI ST_CHNL 
AVL.PROD_AVLJTYP — 1 D f 
AVL.AVL_FOR in ( *R' , *B' ) 

If a product does not meet the above selection criteria, it's entry will be removed from the applicable product linked 
list. 

If there are no applicable products remaining in the linked list, a message will be returned to the caller indicating "No 
Applicable Products". 

If more than one product is available for a specified distribution channel and the distribution channel is not a 'Rental 
Branch', then the product defined as 'P'rimary will be returned by APS. If no product is defined as primary, a 
message will be returned to the caller indicating that 'there is more than one product available for this distribution 
channel". 

The remaining products in the linked list will be used to populate the outputs of the APS. 

The list of applicable products returned by the APS will be limited to no more than 25 for calls with a distribution 
channel of 'Rental Branch'. 

Once the outputs have been populated and returned to the caller, the linked list will be deleted. 

If applicable product list returned by the APS has only one entry, then the PRS can be invoked without user 
intervention. 

If the vehicle category is the only optional input parameter not provided, and the resulting applicable product list 
returned by the APS has only one entry, then the PRS can be invoked without user intervention to return rates for all 
car classes attached to the single rate header. 
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3.12 Product Rate Service - PRS 

This service module determines the rate details for the selected product. The PRS is invoked after a call to the APS, 
and is supplied with the unique rate header identifier of the selected product. 

3.1.2.1 Inputs 



standard header 


The content of this header will be 
used for debugging, user test 
support, performance monitoring, 
tuning and error logging 


refer to standard header 
document for layout and 
population rules 


Mandatory 


Client App 


view version 


TUX interface id string 


FN MRENGTV001 VERSION 


Mandatory 


string 


100 


Tux View 


rate_header_key 


Rate Header Unique identifier 


FN MEN RATE HDR ID 


Mandatory 


long 


APS 


res stn id 


Reservation Station ID (Branch) 
Reservation timestamp 


FN MEN RES STN ID 


Mandatory 


string 


11 


Client App 


resjmsp 


Pick-up Station ID (Branch) 


FN MEN RES TMSP 


Mandatory 


string 


13 


Client App 


co stn id 


Pick-up timestamp 


FN MEN CO STN ID 


Mandatory 


string 


11 


Client App 


cojmsp 


FN MEN CO TMSP 


Mandatory 


string 


13 


Client App 


ei stn id 


Return Station ID (Branch) 


FN MEN CI STN ID 


Mandatory 


string 


11 


Client App 


gi_tmsp 


Return timestamp 


FN MEN CI TMSP 


Mandatory 


string 


13 


Client App 


if 


ci_grace_mms 


Return grace minutes 


FN MEN CI GRACE M1NS 


Mandatory 


long 


Client App 


feilling^cycle 


24-hour (H) or Calendar Day (C) 


FN MEN BILLING CYCLE 


Mandatory 


char 


Client App 


fote_detail_key 


Rate Detail Unique Identifier 


FN MEN RATE KEY 


Optional 


long_ 


PRS 


jfehicle_category 


Requested car class 


FN MEN CAT CD 


Optional 


string 


Client App 


vehicle_suffix 

- _ . . , J. I::-. - . ■ 


Requested car class suffix 


MEN CAT CD SFX 


Optional 


Client App 



3s 5 


a - 





standard_header 


view version 

System generated 

rate header key 

9 

res stn id 

0109 

res_tmsp 

200107211315 

co stn id 

0109 

co_tmsp 

200107211315 

ci stn id 

0109 

cLtmsp 

200107221315 

ci_grace_mins 

59 

billing_cycle 

H 

rate_detail_key 

0 | 

vehicle_category 

ECAR 

vehicle_suffrx 

** 




3.1.2.2 Outputs 










Pit 









engine_error 

Server error Code or 0 

FNJ/IENERR_STATUS 

0 

long 

4 

PRS 

enginejnessage 

Server Error Text 

FNJVlEN.ERRJvlESSAGE 

All OK 

string 

100 

PRS 

rental_duration_days 

Rental duration in days 

FNJvlENJRENTAL_DURATION 

1 

long 

4 

PRS 

renta l_du rationjiours 

Rental duration in hours 

FN.MENJ^ENTALJDUR^HOURS 

24 

long 

4 

PRS 

fueLunbkLamt 

Unbundle amount for included fuel 

FNJvlEN_FUEL_JJNBLD_RENT_AMT 

Null 

double 

8 

| PFC 

nurrwecords 

Number of rate records made up of below 
components (1-25) preceeded by an * 

FN_MEN_REC__COUNT 

1 

long 

4 

PRS 
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*vehicle_category 


Car Class 


FN_MEN_CAT_CD 


ECAR 


string 


*vehicle_suffix 


Car class suffix 


FN_MEN_CAT_CD_SFX 


string 


*rate_detail_key 


Unique identifier for rate detail row 


FNJVEN_RATEJ<EY 


21 


*total_seat_price 


(hourly_count * hourly_rate) + 
{daily_count * daily_ra7e) + 
(weekly_count * weekly_rate) + 
(monthly_count * monthly_rate) + 
(extra Jiourly_count * extra_hourly_rate)+ 
(extra_daily_count * extra_daily_rate) 


FN_MEN_SEAT_PRC 


15.99 


long 


double 


*totai_free_miles 


(hourly_count * hourlyjniles) + 
<daily_count * daiiy_miies) + 
(weekly_count * weeklyjniles) + 
(monthly^count * month7y_miles) + 

(extra_hourly_count*extra_hourly_mi!es)+ 
(extra„daily_count * extra_daily_miles) 


FN _MEN_TOT_FREE_MI LES 


150 


long 


*excess_mileage_fee 
•Unlimited miles ind 


Excess mileage fee 


FN MEN XS MIL FEE 


Unlimited mileage indicator 


.30 


FN_MEN_UNLf MITES MILES IND 


N 


double 


char 


*drop_fee 


*hourly_count 


Drop charge associated to one-way rental 


Number of hour units 


FN MEN OWY CHG 


Nul 


FNMEN TM HR CNT 


double 


8 


long 


*hourly_rate 


Hourly rate 


FN MEN TM HR RATE 


5.99 


double 


8 


*houriy„miles 


Hourly free miles 


FN MEN TM HR MIL 


Null 


long 


*daiiy_count 


Number of day units 


FN MEN TM DY CNT 


long 


*dally_rate 


Daily rate 


FN MEN TM DY RATE 


15.99 


double 


8 


miles 


<ly_count 


Daily free miles 


FN MEN TM DY MIL 


Number of week units 


150 


FNMEN TM WK CNT 


long 


long 


*Wj 


rate 


*w^§kly_miles 


Weekly rate 


FNMENJM WK RATE 


Weekly free miles 


79.99 


FN MEN TM WK MIL 


Null 


double 


long 


4 


m lnthly^count 


Number of month units 


FN MEN TM MO CNT 


Jong. 


4 


*mbqthly_rate 


Monthly rate 


FNJMENJTM_.MO_RATE 


Null 


double 


8 


*mfffithly_miles 


Monthly free miles 


FN MEN TM MO MIL 


Null 


JonsL 


4 


*ew-P_hourly_count 


Number of extra hour units 


FNJVIEN TM XTR HR CNT 


long 


*extra_hourly_rate 


Extra hour rate 


FN MEN TM XTR HR RATE 


5.99 


double 


extra_hourly_miles 


*e#li_daily_count 


Extra hour free miles 


FN MEN TM XTR HR MIL 


Null 


long 


Number of extra day units 


FN MEN TM XTR DY CNT 


jona. 


*e£fea_daily_rate 


*e#a_daily_miles 


Extra day rate 


qusfejd 


Extra day free miles 


FN_MEN_TM_XTR_DY_RATE 


15.99 


FN MEN TM XTR DY MIL 


Null 


Unique identifier for qualifier row 


FN MEN RATE QLFR ID 


14 


double 


long 


lon^ 


eajjest co dow 


earnest co time 


Earliest checkout day of week (1-7) 


FN MEN EARLIEST CO DOW 


THU 


latgsjt ci dow 


Earliest checkout time (seconds) 


FNMEN EARLIEST CO TIME 


*min_days 


Latest checkin day of week (1-7) 


43200 


FN MEN LATEST CI DOW 


MON 


Minimum rental duration (days) 


FN MEN MIN DRTN 


string 


long 


string 


long 


*max_days 


Maximum rental duration (days) 


FN MEN MAX DRTN 
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Note: Bolded fields represent output values associated with the specials design document pending approval. Values 
preceded by an * denote that up to 25 values can be returned. 

3.1 .2.3 Detailed Process Flow 


Receive and Validate 
Inputs 


Rate Dtfaii Usages 


Reservation DateTime 
Checkout DateTinie 
Rate Header ID 



Reservation DateTims 
Checkout DateTime 
Distribution Chamsl 



Check for 


Shared 


Rates 



Retrieve 


Rates 



Retrieve 


Rate 


Adjustment 

i 


Calculate 


Counts 


'OPTIMIZE 1 

i 


Populate 


Outputs 



Reservation DateTinie 
Checkout DateTime 
Rate Header ID 
Qual Associations 


Rate Details 


Reservation DateTime 
Checkout DofeTime 
Rate Header ID 


The PRS will validate that the Reservation DateTime, Pick-up DateTime, and Return DateTime are valid. The valid 
format for input dates is YYYYMMDDHH24MI. For example, 20010721 1315 would represent July 21, 2001 
1:15pm. 

If the input dates fail the validation checks, the PRS will return an error to its caller along with a message indicating 
"Invalid Dates". 

The PRS will determine the qualifier associated to the rate header by querying the qualification tables: 
The following constraints will be used when querying the qualification tables: 

KDB RNT_DRTN_JBND S 

RHQA RATE_HEADERjQUAL_AS SN 

Reservation DateTime BETWEEN RHQA.RES_START_DT and RHQA.RES_END_DT 
Pick-up DateTime BETWEEN RHQA.EFFC_STARTJ3T and RHQA . EFFC_END_DT 
RDB . DRTN_BND_CD = RHQA , RDB_DRTN_BND__CD 
Rate Header ID = RHQA.RH_RTHJJNIQ_ID 

If there are no result rows, the PRS will return a message indicating "Data setup error - No qualifier defined for Rate 
Header 55 . 


The retrieved row will contain qualification rules for the product. These qualification rules are: 
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Minimum rental duration 
Maximum rental duration 
Must include days 
Must exclude days 
Required overnight keeps 
Pick-up start/end time 
Minimum charge days 

If the product fails to meet any of the qualification rules, then the userjnfbmessage will be set to a message 
indicating the reason code for the disqualification (e.g. Product failed minimum number of rental days). 

If the Return Branch id different than the Pick-up Branch, the PRS will determine if there are any drop charges by 
querying the DROP_CHARGES table. 

The following criteria will be used when querying the DROPCHARGES table: 

DPCH DROPjCHARGES 

Reservation DateTime BETWEEN DPCH . RES_START__DT and DPCH . RES_END_DT 

Pick-up DateTime BETWEEN DPCH.EFFC_ST_DT and DPCH . EFFC_END_DT 

Pick-up Branch - DPCH.STN_STN_ID 

Car Class = DPCH . VCT_CAT_CD 

Return Branch « DPCH_STN_STN_IDJDROPOFF 

Rate Header ID = DPCH.RATES_HEADER_RTH_UNIQ_ID 

If the rate header indicates that fuel is included with the selected product, the PRS will determine the unbundling 
(back-out) amount for the fuel charges. 

The following criteria will be used when querying the PROD_FUEL_CHGS table: 

PFC PROD FUEL CHARGES 


The PRS will determine if the supplied rate header identifier uses the rates of another rate header (shared rates) by 
querying the RATE_DETAILJJSAGES table. 

The following constraints will be used when querying the RATE_DETAIL_USAGES table: 


Reservation DateTime BETWEEN RDU. RESIST ARTJDT and RDU . RES_END_DT 
Pick-up DateTime BETWEEN RDU . CO_START_DT and RDU . CO__END_DT 
Rate Header ID - RDU . RH_RTH_UNIQ_ID 

The internal variable RATEHDRJD will now contain the unique identifier of the rate header which will be used 
when retrieving the rate details. 

The PRS will then retrieve the vehicle rates by querying the RATE JDET AILS table. 

If the vehicle category is supplied as input, then the PRS will search for rate details with the following order of 


Reservation DateTime BETWEEN PFC . RES_START_DT and PFC.RES_END_DT 
Pick-up DateTime BETWEEN PFC.EFFC_STRT_DT and PFC . EFFC_END_DT 
Product instance code « PFC. PIN PROD INST CD 


RATE DETAIL USAGES 


precedence: 


1. Specific Vehicle Category (e.g. ECAR01) 

2 . Root Car Class (for North America only - US,CA) (e.g. ECAR) 
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The order of precedence for vehicle category selection is detailed in the Vehicle Category Design Document. 

If the requested vehicle category is supplied as input, then the following constraints will be used when querying the 
RATEJDETAILS table: ' 5 

RTD RATEJDETAILS 

Reservation DateTime BETWEEN RTD . RES_STRTJ)T and RTD. RES END DT 
Pick-up DateTime BETWEEN RTD. CO STRT DT and RTD. CO END DT 
RTD.AUTH_FLG = "A' ~ ~~ 

Vehicle Category = RTD. VCT_CAT_CD 
RATE_HDR_I D = RTD . RH_RTH_UNIQ_ID 

If the requested vehicle category is not supplied as input, all effective vehicle rates defined for the RATEHDRID 
will be retrieved 

If the requested vehicle category is not supplied as input, the following constraints will be used when querying the 
RATE_DETAILS table: 

RTD RATE_DETAILS 

Reservation DateTime BETWEEN RTD . RES_STRT_DT and RTD.RESJEND DT 
Pick-up DateTime BETWEEN RTD. CO_STRT DT and RTD. CO END DT 
RTD.AUTH_FLG - *A' ~ ~ ~ 

RATE_HDR_I D = RTD . RH_RTH_UNIQ_ID 

If the rate detail key is supplied as input, the PRS will skip the above steps of rate qualification, rate sharing, and rate 
retrieval by RATE HDR ID, and retrieve the unique row from the RATEJDETAILS table for rate calculation 
purposes. 

If the rate detail key is supplied as input, the following constraints will be used when querying the RATE DETAILS 
table: 

RTD RATEJDETAILS 

Rate Details Key = RTD.RTD_ID 

If the rate retrieval query yields no result rows, then a message will be returned to the caller indicating "No valid rates 
found". 


As a part of iteration 3. the rate detail records supported bv VRS can be of Time and Mileage rate type or Bid price 
rate type. Bid price rate type is used by UM locations of ERAC 

The PRS w ill then calculate the rate adjustment defined for the selected rate header and the specified distribution 
channel hi erarchy. Rate adjustment can be defined as a percentage or an amount. Different percentages or amounts 
can be defined for the daily rate, weekly rate and monthly rate. The daily, weekly, monthly charge amounts of the 
selected rate are adjusted (reduced or increased) by the corresponding rate adjustment amounts defined for those 
charge freq uencies. The rate adjustment is always included in a rate returned by PRS. PRS uses the adjusted rate for 
the calculation of charge frequency counts. The rate adjustment is defined for a given rate header (product ± location) 
. an effective date range and for all vehicle car class codes. The distribution channel hierarchy provided by the client 
is used to select an appropriate rate adjustment record for the selected rate header. 

The PRS will then calculate the unit counts (frequency) of each of the vehicle rate components. 
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The PRS will use the billing cycle supplied as input to determine the unit counts. If the billing cycle input value is set 
to 4 C, then calendar rate calculations will be used. If the billing cycle input value is not set to 'C\ then 24-hour rate 
calculations will be used. 
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Calendar day and 24-hour rate calculations would be as follows: 


Pick Up 

Return 

Calendar Days 
(Calculated) 

24 Hour 


Feb 14 10:00 AM 

Feb 15 10:00 AM 

1 day 

lday 

Feb 14 10:00 AM 

Feb 15 10:59 AM 

1 day 

1 day 

59 minute grace 
period 

Feb 14 10:00 AM 

Feb 15 11:00 AM 

2 days 

1 day + 1 hour 


Feb 14 10:00 AM 

Feb 15 11:59 PM 

2 days 

2 days 

Feb 14 10:00 AM 

Feb 16 12:00 AM 

3 days 

2 days 

Feb 14 10:00 AM 

Feb 17 10:00 AM 

4 days 

3 days 


In this example, it is assumed that the hourly rate is one fourth the daily rate. 

The PRS will optimize the unit counts of each of the rate components (e.g. use the daily rate until the weekly rate 
becomes cheaper). In case of a Bid price rate type, 1 day rate, 2 day rate, 3 day rate or 4 day rate is used if the length 
of rental is 12, 3 or 4 days respectively. If the rental length is between 5 to 7 days then the weekly rate is used. In the 
case of time and mileage rates, the weekly rate is used if the daily rate multiplied bv the number of days of the rental 
becomes higher than corresponding weekly charge. 

The retrieved rate details and calculated unit counts will be used to populate the outputs of the PRS. 

The selected rate adjustment amounts are returned as a part of output by PRS. As specified earlier the rate adjustment 
amounts are already included in a rate amount returned by PRS, so these amounts are for client information only and 
these amounts need not be stored as a part of the transaction. Client can use this information to generate/display 
appropriate text message for a customer. 

The list of rate records returned by the PRS will be limited to no more than 25. 

If the vehicle category is supplied as input, and a valid rate record is returned, then the sub-engines (Coverage Engine, 
Equipment Engine, General Conditions Engine and Ancillary Charge Engine) can be invoked without user 
intervention. 
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3.1.3 Special Products Implementation 

This document describes the current proposal for implementing the Enterprise 'special' within VRS for Iteration 3. 
Although the document refers primarily to weekend specials, the proposal applies to non-weekend specials as well 

3.1.3.1 Enterprise Requirements for Specials 

Definition of Specials: Specials are the vehicle rates available for limited period of time. In addition, special vehicle 
rates will have associated qualifications which will allow user to specify the day and time when the special rate is 
applicable for pick up and return. 

■ For ERAC, the validity/qualification for the special is applicable for a special rate only. If the user wants to 
keep the car for a longer period of time, the user is charged the primary standard Retail rate applicable for 
that pick up location. 

■ The next requirement is that when the reservation location and the pick up location are the same, the special 
product is returned even when the pick up date and time are not within the limits of qualifications associated 
with that Rates_Header. Under these circumstances, the Enterprise rental agent will decide the date/time of 
the rental that the special rate is valid and the period of the rental that the primaiy standard retail rate is valid. 
The applicability of the rate, charge type and charge frequency will be the same as if we have received two or 
more independent rate engine transactions. 

■ Special products/rates are returned by the Rates Engine only if specifically requested by the caller. The caller 
must provide the rate source of 'S'pecial for the Rates Engine to return the special products. 

■ All additional charges valid for the rental like coverage charges and equipment will not be defined for the 
special product type. For a given transaction, the coverage charges and equipment rates will be the same as 
those defined for the product type of 4 R'etail. 


3.1.3.2 Design Considerations/Constraints 

Specials will be designated by the product type of 'S' for special. 

Specials will be returned by Rates Engine when the input product type/rate source is 'S'pecial. 

For reservations other than those made at the pickup branch, the special products are returned as a valid product by 
rate engine only if all the qualifications for pick up day/time and minimum/maximum days of the rental are satisfied. 


3.1.3.3 Detailed Design Approach 

Under this proposal, two separate products will potentially be used to return a special rate (like weekend rate) (if 
available and applicable). The weekend special product specifies which days of the week are considered weekend 
days and what the rates for those days are. The primary standard retail rate applicable at a given pick up location will 
be used for any rental days that fall outside the special period. 
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3J.3.4 Weekend Special Business Rules and Requirements 

The VRS rates engine will only attempt to retrieve weekend special type rates if the input rate source is "S" (Special). 

There are two sets of rates associated with a weekend special. The first set of rate represents the daily rate associated 
with rental days that fall within the weekend period defined by the associated rate qualification. The second set of 
rates cover any rental days that fall outside the weekend period. 

The weekend specific rates will be maintained for the weekend special product. The rates for any days that fall outside 
the weekend period will be retrieved from the primary retail product applicable at the pick up branch. 

The user responsible for setting up weekend specials will use the VRS rate qualification to define when the weekend 
rates first apply (earliest pick up day of week and time), and the day of week the weekend rates end. The weekend 
special specific fields on the VRS rate qualification are : 

Earliest Pick Up Day of Week 
Earliest Pick Up Time of Day 

Latest Pick Up Day of Week 
Latest Pick Up Time of Day 

Return Latest Day of Week 

The VRS rates engine will use the fields listed above to determine if weekend special rates are applicable in a given 
rental situation and which days of a rental the weekend rates apply. 

The pick up earliest day of week and time generally describes the earliest point in a week that the weekend special is 
available for rental. If the reservation source is the same as the pick up branch, the counter agent will have the option 
of overriding the pick up earliest day of week and time. These fields also define when the weekend rates first apply. 

The pick up latest day of week and time specifies the latest point in a week that a weekend special is available for pick 
up. This value is normally set to one day prior to the return latest day of week. 

The return latest day of week and the pick up time of the rental transaction (if return day is beyond the special end day 
of week) marks the end of the weekend period. Any portion of a rental that goes beyond this is charged at the 
applicable primary retail rate for the pick up branch. 

The rules regarding the earliest pick up day of week and time depend upon the reservation source (distribution 
channel) used for the rental transaction, as explained below, 

If the reservation source is anywhere other than the pickup branch, the following rules apply: 

If the input pick up day of week and time is prior to the earliest pick up day of week and time on the qualification, a 
message will be returned indicating no applicable special products were found. 

If the input pick up day of week and time is within the pick up and earliest and latest day of week and time specified 
on the qualification, the rates engine will return both the weekend special rate and the rate for the primary retail 
product for the given pick up branch. The retrieval of the primary retail rate will be transparent to the end user other 
than the fact that it is available. 

The return latest day of week on the rate qualification is not used to determine product applicability. The renter can 
return the vehicle after the return latest day of week and still qualify for the rental. The primary retail rate for the pick 
up location will apply to the portion of the rental that goes past the return latest day of week. 
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If the reservation source is the pickup branch, the following rules apply: 


If the input pick up day of week and time is prior to the earliest pick up day of week and time on the qualification the 
rates engine will return both the weekend special rate and the rate for the primary retail product for the given pick up 
branch. Amessagewill be returned to the user indicating that the rental period begins prior to the pickup earliest day 
of week and/or time on the qualification. The agent will thenhavethe option of either disregarding theiaessage and 
allowing the rental, or calling the rates engine again with a rate source other than "S'\ 

If the input pick up day of week and time is within the pick up earliest and latest day of week and time specified on 
the qualification, the rates engine will return both the weekend special rate and the rate for the primary retail product 
forthe grven pick up branch. 

As with the case where the reservation source is other than the pick up branch, the return latest day of week on the rate 
qualification is not used to determine product applicahility. The renter can return the vehicle after the return latest day 
of week and still qualify for the rental. The primary retail rate for the pick up location will apply to the portion of the 
rental that goes past the return latest day of week. 


3.L3.5 Scenarios 

Pickup and Return Qualification forthe special product is specified as: 
Weekend Special 

QualPickUp Earliest Day of Week: Thursday 
Qual Pick Up Earliest Time: 12: 00 noon 

Qual Return Latest Day Of Week: Monday 

Weekend Special Daily Rate: 12.00 
No hourly rate for tbe special Product 

Primary Mall Rate 

Standard Retail Daily Rate: 20.00 
Standard Retail Hourly Rate: 10.00 
CForthis scenario assume that there is no weekly or monthly rate) 

API modification for PRS service to support Special Product : 

New rate engine output fields have been created to explicitly store special daily rate amounts, special daily duration 
counts and before special period day and week duration counts . The before special period day and week duration 
cowit(before_day_countmd before jweek_count) fields will be used to store the day and week durations preceding 
the special period. Post special durations counts will be stored in the existing day/week/Month rental count fields. 

In addition to the above modifications, two additional fields will be added to represent special 
validity date range for the transaction under consideration. 

EARXJEST_SPECIAL_START __DT_TM 

and 


LATEST SPECIAL END DT TM 
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3.1.3.5.1 Scenario 1 

This scenario shows a simple case where the entire rental period falls within the pick up earliest and return latest days 
specified on the associated qual. The reservation agent has requested a Special. 

Res and Rental Info 

Reservation Source: Other than pick up branch 

Pick Up Day of Week per Reservation: Thursday 

Pick Up Time per Reservation: 1 :00 p.m. 

Return Day of Week per Reservation: Monday 
Return Time per Reservation: 1 1 :00 a.m. 

Rates Engine Response 

The rates engine would retrieve both the weekend special rates: $12.00/day and the primary retail rate $20.00/day - 
$ 1 0.00/hour. These rate were returned because: 

A weekend special product had rates available at the input pick up location, 
p The user requested a Special 

The input pick up day of week and time was greater than or equal to the earliest pick up day of week and time on the 
Special rate qualification. 

Four rental days fell within the special period defined on the qualification and were charged at the special rate of 
$12.0O/day 

C J Since the rental was completely within the weekend period specified on the qualification, the primary retail rate was 
5 J not used. 

W 

in 

I 


2 i 


111 
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Scenario 1 Rates Engine Output 


H. 
fll 

IP 
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^^^^^^^^ 

engine__error 

0 

enginejnessage 

Ail OK 

userjnfo„message 

OK 

rental_du ration_days 

4 

rentaLduration^hours 

94 

droo fee 

0.00 1 

fi iaI nnhlH ami 
J UtSI Ui \vl\Jt m jM \ 11 

0 00 

VtVV 

num records 

1 

vehicle_category 

ECAR 

rate_detail in .key 

21 

total seat price 

48.00 

totaLfree_mi!es 

0 

excess mileage fee 

0.00 I 

hourly_count 

0 

hour!y_rate 

10.00 

hourly_miles 

0 

daily_count 

0 

dally rate 

20.00 

dally miles 

0 

weekly_count 

0 

weekly_rate 

0.00 

weekly miles 

0 

month ly_count 

0 | 

monthly_rate 

0.00 

month lv miles 

0 

extra hourly count 

0 

extra hourly rate 

0.00 

extra_hourly_miles 

0 

extra daily count 

0 

extra daily rate 

0.00 

extra daily miles 

0 

quaUd 

14 

earliest co dow 

THU 

earliest co time 

43200 

latest ci dow 

MON 

min days 

0 1 

max_days 

999 

min_charge_days 

0 

Earliest Special start dt 

200108091300 

Latest Special end dt 

200108131300 

SpeciaI_daiIy_count 

4 

SpeciaLdailyjrate 

12.00 

SpeciaLdaily_miles 

0 

Before_day_count 

0 

Before_week_count 

0 


Pick up dt-tm 
Return dt-tim 


200108091300 
200108131100 


Rates from the Primary Standard 
)>■ Default Retail Product 
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3.1.3.5.2 Scenario 2 

This scenario shows a case where the pick up day of week and/or time for the rental is prior to the earliest pick up day 
of week and/or time specified on the associated qual. The reservation agent has requested a Special. No special rates 
will be returned. At this point, the reservation agent will probably attempt the reservation with a different input rate 
source (i.e. Retail). 


Res and Rental Info: 


Reservation Source: 
Pick Up Day of Week per Reservation: 
Pick Up Time per Reservation: 
Return Day of Week per Reservation: 
Return Time per Reservation: 


Other than pick up branch 

Thursday 

10:00 a.m. 

Monday 

10:00 a.m. 


Rates Engine Response: 

The rates engine would return a message indicating no applicable product or rates found. This message was returned 
because: 

The pickup time passed by the caller was earlier than the pick up earliest time on the qual 
f!!| The reservation source was other than the pick up branch 


J** 


I * 3 


Si 

m 


3 s =5 

lab 
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Scenario 2 Rates Engine Output 




engine_error 

16401 

engine_message 

No applicable specials 

userjnfojnessage 

OK 

rentai_duration_days 

4 

rental_durationJiours 

96 

dropjfee 

0.00 

fueLunbId_amt 

0.00 

num records 

o 

vehicle cateaorv 

Null 

rate_detai l_key 

Q 

total seat pnce 

0,00 

totaljreejniles 

0 

excess_mileage_fee 

0.00 

! hour[y_count 

0 

hourly_rate 

0.00 

hourlyjrules 

0 

dai!y_count 

0 

; daily_rate 

0.00 I 

daily_miles 

0 

; weeklyjxunt 

0 

weekly_rate 

0.00 

weekly miles 

0 

| monthiy_count 

0 

monthly_rate 

0.00 

monthly_miles 

0 

extra__hourIy_count 

0 

extra_hourly_rate 

0.00 

extra_hourly_miles 

0 

extra_daily_count 

0 

extra_daily_rate 

0.00 

extra_daily_miles 

0 

quaMd 

0 

earliest co dow 

0 

earliest co time 

0 

latest_ci m dow 

0 

mill Qayo 

n 
u 

maxjjays 

0 

min_charge_days 

0 

Earliest Special start dt 


Latest Special end dt 


SpeciaLdaily_count 

0 

SpeciaLdai!y_rate 

0.00 

SpeciaLdai1y_miles 

0 

Before_day_count 

0 

Before_week_count 

0 


Pick up dt-tm 
Return dt-tim 


200108091000 
200108130800 
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3.1.3.5.3 Scenario 3 

This scenario shows a case where the rental begins within the pick up earliest and latest period specified on the 
associated qualification, but ends after the return latest day of week. The reservation agent has requested a Special. 
The total price returned by the rates engine will be a combination of the weekend rate and the primary retail rate. 

Res and Rental Info: 

Reservation Source: Other than pick up branch 

Pick Up Day of Week per Reservation: Friday 

Pick Up Time per Reservation: 1 : 00 p.m. 

Return Day of Week per Reservation: Tuesday 
Return Time per Reservation: 11:00 a.m. 

Rates Engine Response: 

1*1 The rates engine would return 3 days at the $12.00/day weekend special rate (Friday through Monday) and one day at 
p the $20.00/day primary retail rate (Monday to Tuesday). This rate was returned because: 
p ■ A weekend special product had rates available at the input pick up location, 
fj j ■ The user requested a Special 

■ The input pick up day of week and time was greater than or equal to the earliest pick up day of week and 
time on the Special rate qualification. 

■ Three of the rental days fell within the special period defined on the qualification and were charged at the 
special rate of $12.00/day 

■ One of the rental days at the end of the rental fell outside the weekend period and was charged at the 
primary retail rate of S20.00/day . 
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Scenario 3 Rates Engine Output 
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engine^error 

o 

engine_message 

All OK 

user_jnfo_message 

OK 

re nta l_d u ration_d ays 

4 

rental duration hours 

94 

arop_jee 

c\ fin \ 
u.uu 

tu e i_u n Dia_ a mt 

U.UU 

num records 

1 

vehicle_category 

ECAR 

rate_detail_key 

21 

total_seat_price 

56.00 

total free miles 

0 ! 

excess mileage_fee 

0.00 

hourly_count 

0 

hourly_rate 

10.00 

hourlyjniles 

0 

daily_count 

1 

daily_rate 

20.00 

daiiy_miles 

0 

weekly_count 

0 

weekly_rate 

0.00 

weekly miles 

0 

Monthly count 

0 

Monthlyjrate 

0.00 j 

Monthly miles 

o 

extra hourlv count 

o 

extra hourlv rate 

0.00 

extra hourlv miles 

o 

extra_daily_count 

0 

extra_daiiy_rate 

0.00 

extra__daily_miles 

0 

qualjd 

14 

earliest co dow 

THU 

earliest co time 

43200 

latest ci dow 

MON 

min_days 

0 

max_days 

999 

min_charge_days 

0 

Earliest Special start dt 

200108091300 

1 Latest Special end dt 

200108131300 

SpeciaLdaily_count 

3 

Special_daily_rate 

12.00 

SpeciaLdaily_mites 

0 

Before_day_count 

0 

Before week count 

0 i 


Pick up dt-tm 
Return dt-tim 


200108101300 
200108141100 
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3.1.3.5.4 Scenario 4 

This scenario illustrates the case where the counter agent overrides the earliest pick up time on the associated qual. 
The agent has requested a Special Note that in this example, the vehicle is picked up on the same calendar day as the 
pick up earliest day of week on the qualification. The actual pick up time is prior to the pick up earliest time on the 
qualification. 

Res and Rental Info: 


Reservation Source: 

Pick Up Day of Week per Reservation: 

Pick Up Time per Reservation: 

Return Day of Week per Reservation: 
Return Time per Reservation: 


Pick up branch 

Thursday 200108091000 
10:00 a.m. 


Monday 
8:00 a.m. 


200108130800 


■lass; 

3' K 

fli 

m 
o 


5 5 

3 
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Rates Engine Response: 

The rates engine will return a message indicating that the rental start day of week and/or time is prior to the pick up 
earliest day of week and time of the special as defined on the associated qual The agent specifically requested a 
Special Should the counter agent decide not to extend any special rates after viewing the message, the input rate 
source can be changed (Le. Retail) and the rates engine called again. 

The rates engine would return four days at the $12,00/day weekend special rate (Thursday through Monday). This rate 
was returned because: 

■ A weekend special product had rates available at the input pick up location. 

■ The user requested a Special 

■ Although the input pick up time was prior to the pick up earliest time on the qualification, the counter agent 
was given the option of overriding the qualification restrictions since the reservation source was the pick up 
branch. The counter agent decided to extend the weekend rates on the applicable days. 

■ Since the actual pick up day of week and the earliest pick up day of week on the qual were the same (the 
vehicle was picked up 2 hours early), the special rate applied for every day of the rental. The earliest special 
start time (and consequently the latest special end time) were implicitly changed to the actual pick up time 
for this rental. 
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Scenario 4 Rates Engine Output 
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0 
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extra_hourly_count 

0 
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0.00 
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0 
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0 
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0 
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14 
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0 

max_days 
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0 
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Latest Special end dt 
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Special_daHy_count 

4 

Special_daily_rate 

12.00 

Special_daily_miles 

50.00 

Before_day_count 

0 
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3.1.3.5.5 Scenario 5 


This scenario illustrates the case where the counter agent overrides the earliest pick up day of week on the 
associated qual and offers the weekend special rate for a portion of the rental. The agent has requested a Special. In 
this example, the vehicle is picked up one calendar day early. 

Res and Rental Info: 

Reservation Source: Pick up branch (Walk Up) 

Pick Up Day of Week per Reservation: Wednesday 

Pick Up Time per Reservation: 3:00 p.m. 

Return Day of Week per Reservation: Monday 
Return Time per Reservation: 1 1 :00 a.m. 


Rates Emine Response: 

y The rates engine will return a message indicating that the rental start day of week and/or time are prior to the 

!■■? earliest start day of week and time of the special as defined on the associated qual The agent specifically requested a 

W Special Should the counter agent decide not to extend any special rates after viewing the message, the input rate 

Pi source can be changed (i.e. Retail) and the rates engine called again. 

m 

' * J ■ The rates engine would return one day at the $20.00/day primary retail rate (Wednesday to Thursday) and 4 

W days at the $12.00/day weekend special rate (Thursday through Monday). This rate was returned because: 

ii -A weekend special product had rates available at the input pick up location. 

M -The user requested a Special 

|ll -The reservation location and pick-up location were the same. 

Hi 

Si ■ Although the pick up day of week was prior to the pick up earliest day of week on the qual, the counter agent 

O was given the option of overriding the qual restrictions since the reservation source was the pick up branch. 
The agent decided to extend the weekend rates on the applicable days. 

■ Four of the rental days fell within the special period defined on the qual (Thursday 3 :00 through Monday)and 
were charged at the special rate of $12.00/day 

■ The first day of the rental (Wednesday 3 :00 through Thursday 3 :00 started prior to the pick up earliest day of 
week on the qual The primary retail rate was charged for this rental day. 
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Scenario 5 Rates Engine Output 


f 1 

If I 

m 
a 
si 

I'M 

Hi 


IP 




engine error ( 

3 1 

engine message j 

Ml OK 

userjnfojnessage ! 

i 

Earliest pickup qualification 
lot met 

rental duration days I 

5 S 

rental_duration_hours 

116 

drop fee 

0.00 

fuel unbld amt 

0,00 

num recoras 


ven ici e_catego ry 


rate detail key 

21 

total seat price 

68.00 

total free miles 


excess mileage fee 

0.00 i 

hourly count 


hourly rate 

0.00 

hourly miles 


daily count 


daily rate 

20.00 

daily miles 


weekly count 


weekly rate 

0.00 

weekly miles 


monthly count 

0 

monthly_rate 

0.00 

monthly miles 

0 

| extra hourly count 

0 

extra hourly rate 

10.00 

extra hourly miles 

0 

extra daily count 

0 

extra daily^rate 

0.00 

extra daily miles 

0 

qua! id 

14 

earliest co dow 

THU 

earliest cojime 

43200 

latest ci dow 

MON 

min days 

0 

max days 

999 

| min charge days 

0 

Earliest Special start dt 

200108091500 

Latest Speciai end dt 

200108131500 

Special daily count 

4 

Special daily rate 

12.00 

Special daily_miles 

50.00 

Before_day_count 

1 

Before week count 

0 


Pick up dt-tm 
Return dt-tim 


200108081500 
200108131100 


Note: In this scenario, the before_day_count indicates the number of days to charge the standard retail rate for this 
transaction (1 x day at $20). 
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3.1.3.5.6 Scenario 6 

This scenario illustrates the case where the counter agent overrides the earliest pick up day of week on the 
associated qualification and offers the weekend special rate for a portion of the rental. In this scenario, the rental also 
extends past the return latest day of week. The agent has requested a Special. In this example, the vehicle is picked up 
one calendar day early. 

Res and Rental Info: 

Reservation Source: Pick up branch (Walk Up) 

Pick Up Day of Week per Reservation: Wednesday 

Pick Up Time per Reservation: 3:00 p.m. 

Return Day of Week per Reservation: Tuesday 

Return Time per Reservation: 11 :0O a.m. 

Rates Ensine Response: 

The rates engine will return a message indicating that the rental start day of week and/or time are prior to the 
earliest start day of week and time of the special as defined on the associated qual The agent specifically requested a 
Special Should the counter agent decide not to extend any special rates after viewing the message, the input rate 
source can be changed (ie. Retail) and the rates engine called again. 

The rates engine would return two days at the $20.00/day primary retail rate (Wednesday to Thursday and Monday 
to Tuesday) and 4 days at the $12.00/day weekend special rate (Thursday through Monday). This rate was returned 
because: 

■ A weekend special product had rates available at the input pick up location. 

■ The user requested a Special 

■ Although the pick up day of week was prior to the pick up earliest day of week on the qual, the counter agent 
was given the option of overriding the qual restrictions since the reservation source was the pick up branch. 
The agent decided to extend the weekend rates on the applicable days. 

■ Four of the rental days fell within the special period defined on the qual (Thursday 3 :00 through Monday)and 
were charged at the special rate of $ 12.00/day 

■ The first day of the rental (Wednesday 3:00 through Thursday 3:00 started prior to the pick up earliest day of 
week on the qualification. The last day of the rental (Monday to Tuesday) fell outside the return latest criteria 
on the qualification. The primary retail rate was charged for these two rental days. 

■ Since the actual pick up day of week was overridden, the primary retail rate was charged for the first day of 
the rental. The weekend rate was charged for subsequent days. 
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Scenario 6 Rates Engine Output 


j airs, 
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engine_error 


enginejnessage 

Ml OK 

userjnfojnessage 

Earliest pickup qualification 
not met 

1 rental duration_days 


{ rental_duration_hours 

40 

drop_fee 

0.00 

fuel_unbld_amt 

0.00 

{ lull I icwjiuo 

» 


ECAR 

rate detail_key 

21 

total seat price 

88.00 j 

total free miles 

0 

excess mileage_fee 

0.00 \ 

hourly count 

0 

hourly rate 

10.00 

hourly miles 

0 

daily count 

1 

daily rate 

20.00 

daily miles 

0 

weekly count 

0 

weekly rate 

0.00 

weekly miles 

0 

monthly count 

0 

monthlyjrate 

0.00 

monthly miles 

o I 

extra hourly count 

0 i 

extra hourlyjrate 

0.00 * 

extra hourly_miles 

0 

extra daily_count 

0 

extra daily_jate 

0.00 

extra daily_miles 

0 

qual id 

14 

earliest co dow 

*T*I II 1 

THU 

earliest cojime 

4o200 

| latest ci dow 

MON 

nun uays 

o 

max days 

999 

min charge_days 

0 

Earliest Special start dt-tm 

200108091500 

\ Latest Special end dt-tm 

200108131500 

Special_daily_count 

4 

| SpeciaLdaily_rate 

12.00 

Before day_count 

1 1 

Special_daily_miles 

50.00 

Before week count 

0 


Pick up dt-tm 
Return dt-tim 


200108081500 
200108141100 


Note: In this scenario, the before_day__count captures the day count preceding the special period and indicates the 
number of days to charge the standard retail rate for this transaction (1 x day at $20). The day_count value captures 
the day count succeeding the special period and indicates the number of days to charge the standard retail rate for the 
transaction (1 x day at $20). 


3.1.3.6 Qualification Override Rules (For Open Ticket and Counter Agent) 
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If the counter agent chooses to allow a weekend special to go out prior to the pick up earliest day of week and time on 
the qual, the following default rules apply: 

If the actual pick up day of week is the same as the pick up earliest day of week on the qual (Only the pick up time 
has been moved forward): 

■ The pick up earliest time implicitly becomes the actual pick up time for this rental 

■ The weekend rate applies to the entire first day of the rental 


Example 

Qual Pick Up Earliest Day of Week: 
Qual Pick Up Earliest Time: 
Qual Return Latest Day Of Week: 

Actual Pick Up Day of Week: 
Actual Pick Up Time of Day: 
Actual Return Date: 


Thursday 
12:00 noon 
Monday 

Thursday 
9:00 a.m. 
Monday 


Given the scenario above, the weekend rate would be charged for the entire duration of the rental. The Pick Up 
Earliest Time of Day on the qualification was implicitly changed to 9:00 a.m. for this rental. 

If the actual pick up day of week is prior to the pick up earliest on the qualification: 

■ The primary retail rate is charged for each 24 hour period on the rental prior to the pick up earliest day on the 
qualification 

■ The weekend rate is charged for each rental day that begins within the pick up earliest day of week and return 
latest day of week 


Example 

Qual Pick Up Earliest Day of Week: 
Qual Pick Up Earliest Time: 
Qual Return Latest Day Of Week: 

Actual Pick Up Day of Week: 
Actual Pick Up Time of Day: 
Actual Return Date: 


Thursday 
12:00 noon 
Monday 

Wednesday 
9:00 a.m. 
Monday 


Given the scenario above, the primary retail rate would be charged for the first 24 hour period. After this time, the 
rental falls within the pick up earliest and return latest days of week, and the weekend rate would be charged for the 
remainder of the rental. 

The above rules outline default processing when the pick up earliest day of week and/or time is overridden. It is 
assumed that the reservation/open ticket user interface screen will allow the agent to change the primary 
retail/weekend rate allocations if a given rental situation warrants. 
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4.1 Risks 


4.1.1 Products 


4.1.2 Rate Engine 


4.2 Assumptions 


4.2.1 Products 


ins. . 


Haw 
3i 
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1. 


2. 
3. 

4. 


5. 


6. 


VRS currently attaches rate qualification rules to a rate header. These rules apply to all car classes offered by 
that rate header. Current VRS will meet Enterprise's business need without being modified to attach rate 
qualification rules at the car class level. 

NatRes Deposit, Misc., Mileage, and Guarantee rules can be accommodated with VRS messaging. 
The current VRS method of defining the length of a rental week and rental month meets ERAC's business 
need. 

The VRS pricing engine will search the reservation applicability table (prod_avls) for an exact match based 
on input distribution channel passed by the caller and product location (User Defined Area Name and Type) 
as defined on the selected rate header. 

The VRS pricing engine will traverse applicable entries in the distribution channel hierarchy when searching 
for a match in the rate adjustments table. The location portion of the search will require an exact match on 
user defined area name and type retrieved from Ratesjieader table after traversing the location hierarchy. 
Setting up new (post conversion) bid pricing rate headers will be a manual process. The NatRes to VRS bid 
price bridge process will verify that any rate updates coming across the bridge have a matching VRS rates 
header. Any updates not having a matching VRS rates header will be written to an error file and no rate 
update will occur. 

All rate updates to bid price rates will occur through the NatRes to VRS rate bridge. Mileage limts and 
excess mileage amounts may be maintained in VRS if needed. 
Bid price mileage limits will be established at conversion time. 

Rate Header Discount Y/N flag applies to discounts only; it does not effect distribution channel based rate 
adjustments. 

1 0 . Walk up will not be a separate distribution channel. 

11. Caller will pass applicable portion of distribution channel hierarchy to VRS pricing engine (Le. If renter 
initiated reservation using Travelocity, caller would pass GDS, Sabre, Travelocity). 

12. Conversion of pick up/return rules will be a manual process 

13 Scenarios and illustrations in this document used legacy keys for user defined area name for illustration 
purposes. Actual keys will consist of PeopleSoft code. No "intelligence" is implied by the UDA name. A 
separate process will be responsible for verifying that the a given branch is inserted into the appropriate user 

defined areas. , 

14. For user defined area level Rates Jleader all the BRANCHES belonging to that user defined area should 

have the same currency. 

1 5. The Discountable Flag on the Rates Jieader applies to Discount only, and not to the Rate Adjustments. 


7. 

8. 
9. 


4.2.2 Rate Engine 
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1 . The interfaces for the APS and PRS are described in this document. It will be the callers responsibility to 
determine when to call these services, and to ensure that the pertinent inputs are supplied. 

2. The Rate Engine will not perform currency conversion. All currency related data will be set-up in the same 
currency across all tables per instance. Answer: Mary to confirm. 

3. PRS optimization will be based on actual charged durations. 
4.2.2.1 APS 


4.2.2.2 PRS 


1 . There will be no point-to-point validation for oneway rentals. 

2. The call mode input values of RO,RM,CO,AR,CI,AI do not cause the PRS to behave differently. The are all 
treated the same. Each call to the rate engine will be considered a new call. 

4.2.2.3 Specials 

jw 1 . Rate Engine output for specials need to be transformed multiple start date and end dates and corresponding 
m rate amounts for presentation to GUI as well as for call to the Charge Engine. The rules for this presentation 

Cj are, 


If rental pick up time < special start date-time 

Rental transactions has before special period and charge. 
If rental return time > special end date-time 
JJ* Rental transaction has after special period and charge. 


S S 


3 3 


Special validity period for the transaction is indicated by special start date-time and special end date-time. 

Special start day of week and time as defined for the special rate (and not necessarily for this transaction) is indicated 
by qualification data fields in the form of earliest pick up day of week, earliest pick up time and return latest day of 
week. 


2. If the rental has a before special period, then the special start time will always be a 24 hour increment from 
the corresponding pick up time. 

3 . If the rental has an after special period then the special end time will always be a 24 hour increment from the 
corresponding pick up time. In other words, the fraction period of rental (in terms or hours) will always be 
towards the end of the transaction when transaction uses different rate types as in case of specials. 

4. Portion of the rental period before and after the special validity period are optimized independently even 
though same daily rate may be valid for both portions. Eg. If we have 1 day before and 5 days after, the Rate 
Engine will not offer the weekly rate even though it will be cheaper than 6 times the daily rate. 

5 . Billing cycle for the transaction involving special rate is always 24 hour billing for entire transaction. 

6. There is no hourly rate for the special product. 
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7. Excess mileage charge for the entire transaction will be used from the Primary retail product offered on the 
transaction. 

8. Mileage allowances will be retrieved from special and retail products for the period of rental where special 
and retail rates are valid. 

4.3 Issues 

4.3.1 Products 

1 . Conversion of pick up/return rules will be challenging and needs to be carefully planned and executed 

2. Triggers/Events for the NRA synchronization and other architectural details required for synchronization process 
need to be defined. 

3. The architecture for error reporting as it applies to the Synchronization process is still being defined. 

4. We need to investigate how ship rate to SAFECO functionality will be supported by VRS. 

5. The table layout for the distribution channel hierarchy and where it resides and which functional domains will 
have access to it needs to be specified. The current assumption is that ERAC will define this table. 


4.3.2 Rate Engine 
4.3.2.1 Specials 

jj „ s .... 

^ 1 . As per current assumptions, we will always default return latest time to whatever has been specified as pick 
time for the transaction under consideration. ERAC has expressed the desire to use the latest return time if 
provided in a data and apply accordingly. Our current design proposal does not support that requirement, 
even though we have the data structure (DataBase) to represent that information. 


2. We need to present different business scenario's and identify the processing rules for each of those scenario 
O to fully define the behavior of PRS and optimization routine with return latest time specified as a part of the 
^ rate qualification. 

3 . The dates/times of the charge periods will need to be adjusted from planned date/time to the actual date/time 
by the GUI. 

4. For the optimization of rate counts, in case of bid price rates, we will always apply 1,2,3,4 day rate as per the 
rental duration of the transaction. We will always switch to Weekly rate for rental duration between 5 and 7. 
For other Time and Mileage rates we will use the weekly rate as soon as number of days times daily rate 
becomes higher that corresponding weekly rate. 

5. Our current assumption of returning an error, if special is not valid, may force NATRES to make two 
separate calls so that NATRES can return corresponding retail rate under that scenario. 

6. The business rule which has been defined as part of the ERAC implementation of VRS, where the special 
rate is offered only if rate type of special is specifically requested, needs to be evaluated for NATRES. The 
business rule implemented does not match current NATRES behavior. 
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5.1 Products - Data Model 

Please reference file ProductErd.doc 

5.2 Rates - Data Model 

Please reference file RatesErd.doc 

5.3 Rates Detail - Data Model 

Please reference file RateDetailErd.doc 


Last Save Date:l 1/5/2001 10:18 AM ~™~ Page 1 13 of 1 14 Consolidated Products and Rates Design_l 



ECARS v2.0 - Accurate Out the Door Pricing 
Detailed Design Specification 


perotsystems 


5.4 VRS Process Flow Model 
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/ L:' l \\^Fu»ctfonal, Area";- \^ c -^ 

, 1 AX ax ^ i V,. vk- ■ ^ Brief Description , : > '^v'^ ¥ ■ ^ , ^ 1 

90 

Coverage 

Need ability to price coverage types and additional 
products (ancillary items) by some combination of location 
and default type* 

91 

Coverage 

Enterprise car class definition is potentially composed of 
two components: a car class and a car class suffix. VRS 
raxe Qciaii dues not support any auii ui wax ^ias>a ouiiia. 

118 

Coverage 

Offer weekly, monthly and maximum per rental charge for 
coverage types. 

128 

Coverage 

Need to accommodate station overrides for coverage types. 
For ex. A contract can specify coverage charges for a 
specific coverage but the station might never offer this. 

129 

Coverage 

Need the ability to support Staggered rates for stations that 
need to charge a certain amount for x number of days and 
then another amount from that point on. 

130 

Coverage 

Need anew table to store state mandated limits. The stat 
mandated limit needs to be returned as an output from the 
coverage engine. Only Daily amounts will be retrieved 
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LI Overview 


The purpose of this document is to provide detailed design specifications of how the coverage 
engine component of the Vehicle Rental System (VRS) will be utilized in providing coverage 
types and charges in the retail line of business. This will reflect the complete design at a high 
level with reference to the gaps that will be delivered in iteration 2. This document is specifically 
for the coverage engine. 


ru 


m 

n 13* 


1 z 


In VRS (Vehicle Rental System) the Insurance Types (INSJTYPS) and Insurance Provisions 
(INS JPRVS) tables are the two main entities used to satisfy the coverage (protection) related 
requirements of a rental transaction. 


These entities allow users to classify and relate a set of standard and customized coverage types 
by associating them with combinations of product type, and/or product instance, location based 
C j rate hierarchy and vehicle category. 


The coverage engine of VRS is used to retrieve the set of applicable coverage types and charges 
along with the appropriate applicability status for a specified set of input parameters. 

The design details of these data base entities and their associated engine functionality, as it 
applies to the Retail-SI business type of ERAC, are described in the following sections. 

1.2 Dependencies 

Dependencies with ERAC's test windows. 


1.3 Data Conversion 

High level impacts to data conversion. A separate document will be published for data 
conversion design. 

1.4 Impact Analysis 

This section is not applicable for Iteration 2. This section will be relevant for subsequent 
iterations to track the differences between iteration 3 and 2, iteration 4 and 2 and so on. 
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2.1 Coverage Engine 


2.1.1 Insurance Types Use Case 


The following defines information that pertains to this particular use case. Each piece of 
information is important in understanding the purpose behind the use case. 


Goal In Context: 
Scope: 

Level: 

Pre-Condition: 


Success End Condition: 

Failed End Condition: 
Primary Actor: 
Trigger Event: 


ERAC user maintains the coverage types in the ECARS Insurance Type 
table. 

This use case deals with insert/update activity on the Insurance Type 
and Insurance Packages tables. The main actor is the User responsible 
for maintaining this information. 
Sub functionality 

1 . CRYS entity pre-populated with all the relevant country codes. 

2. RRA_CHG_TYPS pre-populated with all relevant charge 
types. 

Coverage type record created with appropriate database constraints 
defined for Insurance Type entity. 
Coverage type record not created. 

The main actor is the user responsible for maintaining this information. 
Requirement to create new coverage type and/or super type. 


2.1.1.1 Main Success Scenario - Create Insurance Types Records 
2.1.1.1.1 User Creates Coverage Type 

The insurance types entity stores unique coverage type id's for a specific country code. ERAC 
specifies the charges for these coverage types in association with a rental product and/or 
contractual conditions. The detail of how the pricing is done is covered in a separate use case 
document. 


Coverage types are classified as insurances that are similar in nature but offer different levels of 
protection for a specific country. Insurance super types are used to indicate related coverage types 
within VRS. 

Another way of defining coverage is a package coverage type, which is offered as a group of 
different coverage types for a country and priced as a single coverage item. 

Additionally, the ability to define 'state mandated' limits is covered. 
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The details of how these different coverage types are structured within the VRS data model is 
explained below: 

User creates the coverage type record into INS JTYP table. 

In the VRS data model, the INS JTYPS table stores all the valid coverage type codes for a 
specific country. Each coverage type has a description that can be stored in two attributes 75 char 
wide called ins_cnd_lnl and ins_cndjn2. In addition, for each coverage type there is a valid pre- 
defined charge type value. The charge engine uses this at the time of tax calculation and charge 
allocation. We also store the audit information in the form of create user id and create date-time 
for this record as well as the user id and date-time of the last modification. 


Record created with some coverage types described 


Country 

Insurance 
Type 

Insurance Type 
Description 

Charge 
Type 

Super 
Type Code 

Super Type 
Order Number 

Package ID 

DE 

CDW 

Collision Damage 
Waiver 

00006 

CDW 

1 


US 

CDW1 

Collision 
Damage Waiver 
Full 

00006 

CDW 

1 


US 

CDW2 

Collision 
Damage Waiver 
$3000 

00006 

CDW 

2 


US 

CDW3 

Collision 
Damage Waiver 
$5000 

00006 

CDW 

3 


CA 

PAI 

Personal 
Accident Ins 

00007 

PAI 

1 



2.1,1,1.2 Creation of Insurance Super Types 

Insurance super types designate the coverage types which offer the same coverage but with 
varying degree of details. For example, user may want to create the three different flavors of 
Collision Damage Waiver (CDW), as in the preceding table, each with different deductible 
amounts. The Insurance super type indicator identifies all the coverage types that are similar 
while the insurance super type order number indicates the priority order for each coverage type. If 
one of a group of coverage types that are related by a common insurance super type needs to be 
included in any package (group of coverage types) then only the coverage type with highest 
priority would be included as a part of that package. 

At the time of rental user can select only one of the coverage types if two or more coverage types 
offered have same insurance super type. 
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2.1.1.1.3 Insurance Package Creation 


Insurance packages are extensions of coverage types that group two or more of the standard 
coverage types together as a part of one package. 

After creation of a coverage type as discussed above the user will be given the option to create a 
package. This should present to the user a list of coverage types to add. Once all types have been 
added the user maintenance forms should update the coverage type row in the INS_TYPS table 
with the Package ID created. 

The Example below shows the creation of the Peace of Mind (POM) package which consists of 
CDW and PAI. The tables below show the results. 


Insurance Types Table (INS_TYPS) 


Country 

Insurance 
Type 

Insurance Type 
Description 

Charge 
Type 

Super Type 
Code 

Super Type 
Order Number 

Package ID 

US 

CDW1 

Collision Damage 
Waiver 

00006 

CDW 

1 


US 

PAI 

Personal Accident 
Insurance 

00007 

PAI 

1 


. ..... .. . , ,.. , 

POM 

Peaces of Mind 
Package 

00033 

POM 

i . ■ ■ ' . 

•3-'-'. ; 


I nsurance Packages Table (INS PKGS) 


Package Id 

Country 

Insurance 
Type 

Insurance Super Type 

Description 

3 

US 

CDW1 

CDW 

Collision Damage Waiver 

3 

US 

PAI 

PAI 

Personal Accident Insurance 


Note that the Package ID of 3 has been written back to the POM record within the INS JTYPS 
table. 


Additional Rules: 

■ Packages can only be made up of coverage types from the same country. 

■ Only 1 common super type may be used. (i.e. CDW1 and CDW2 may not be combined 
into 1 package). 


2.1.1.1.4 State Mandated Limits 

State mandated limits allow users to store the maximum daily charge limit by coverage type as 
defined by that state. After creation of a coverage type the ability to enter in any state mandated 
limit should be provided. This should allow the user to select which state to add the amount of 
the maximum daily limit. 


Last Save Date: 11/1/2001 9:41 AM 


Page 8 of 37 


Coverage Engine Detail Design_I3 


ECARS v2.0 - Accurate Out the Door Pricing 
Detailed Design Specification 


perotsystems™ 


The example below will show a limit being added for the state of Georgia. 


Mandated 
ID 

Country 

Insurance 
Super Type 

UDA Type 

UDA 

Daily 
Rate 

Start Date 

End Date 

1 

US 

PAI 

ATY ST 

GA 

3.99 

01/01/2001 

12/31/2037 


Additional Rules and Information: 

■ The UDA Type of ATY_ST (state) must exist within the hierarchy. 

■ If a limit is to be defined the state must exist in the STAJUDA table. 

2.1.1.2 Related Information 

Below is the information related to the record in the RRA__CHG_TYPS table that is referenced 
from the INS TYPS table above. 


Charge 
ID 

Description 

Charge 
Category 

Taxable 

00006 

CDW/LDW 

INS 

Y 

00007 

PAI 

INS 

Y 

00033 

Peace of Mind 

INS 

Y 


The details of how the charge types associated with the coverage types will be covered in the 
Tax and Surcharges Document. 
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2.1.2 Insurance Provisions Use Case 

In VRS, the insurance provisions table will be used to associate the coverage types with products 
and/or contracts at the specific location or at the hierarchy level of the location for the pricing 
purpose. This use case explains the design details of insurance provision information to satisfy 
the coverage requirements of Enterprise's retail business as defined in iteration 2 of the project 
scope document. 

ERAC user maintains the Insurance Provisions in the ECARS Insurance 
Provisions table. 

This use case deals with Insert/Update activity on die Insurance 
Provision table as a main actor. 
Sub Functionality 

INS_TYPS table pre-populated with all relevant coverage type 
information. 

PROD_TYPES table pre-populated with all relevant product type 
information. 

USRDFNDAREAS pre-populated with all relevant area types used for 
defining rate hierarchy. 

ERAC entity storing vehicle class reference data has been pre-populated 
with all relevant vehicle category information. 
Insurance provision record created. 

Insurance provision record not created. 

User responsible for maintaining coverage data. 

User who wants to change the coverage composition in terms of charges 
and/or applicability for a location or its hierarchy. 

jli 

0 2,1.2.1 Main Success Scenario - Create Insurance Provision Record 

Insurance Provision record is created. 

The insurance provision table is used to associate coverage types (i.e. PAI, CDW, etc) to a 
particular class of product type, location, or any other hierarchy class level where the rate is being 
defined. 


<!5ST 

IIS 

ii 

w 

'"0 
5 „ 


Goal In Context: 

Scope: 

Level: 

Pre-Condition: 


Success End Condition: 
Failed End Condition: 

si 

U Primary Actor: 
J Trigger Event: 
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2,1.2.2 Related Information 

2.1.2.2.1 Products and Area Hierarchy Classification 

For ERAC implementation the products are classified as 'R'etail, 'S'pecial, Insurance etc. For 
more details refer to the use case related to product data set-up. 

ERAC rate hierarchy for branches currently supports 1 1 levels. For a specific station, the rate at 
the lowest level of hierarchy is always selected. To select a set of coverage charges applicable for 
the specific rental a combination of product type and the rate hierarchy is used. 
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Coverage Tables - ERD 


•IS? 


5 15' 


111 


Cntrctl Cnds 

#*CNTRCTL_CND ID 
CND_DESC 
CTR CONJD 
CUR CURR_CD 
EFF_DT 

FUELJNCL_OVRD_FLG 
INS APPL_OVRD 
1NS_PRM 

NO_EXP_WRNG_FLG 
0 ADV_BKG_OVRD TYP 
0 APPR_STAT 
o AREA_COND_OVRD TYP 


2°' 


Prod Typs 

#*PROD_TYP_CD 
* PROD_TYP_DESC 


In? Prvs 


#*PRMJD 
INTJNS_TYP_ID 
STRTJDT 

PRT PROD TYP CD 
o APPL_STAT~ 
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o VCAJSAT CD SFX 
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0 IP_PROD CAT CD 
o FULL_c6v_FLG 
VCQVJLMT_AMT „ 

Z 

ins Typs 

#*cry ar1mp.cry cd 
#*insJtypjd 

INS_CND~LN1 
INSJTYP DESC 
RCT CHGJTYP 
o ASSOC 
o INS.CND LN2 

INS_SUPERJTYP_CD 
o INS_SUPER_TYP JDRD_NBR 

PKGJD 
0 EC INS ATTCH FLG 
0 CREATE JJSERJD 
0 CREATE_DT 
o LAST UPDT USER ID 
o LAST UPDT DT 


-INP.PRI- 


#*PROD INST_CD 
#*VER NBR 
airlTne TICKET_REQDJND 
AUTH_STAT 
AUTO RECMPTJVT 
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-PRf OF- 


Prods 

#*PRODJD 

* PRODJ3ESC 

* PRT_PROD_TYP_CD 


-INPJJDA- 


Ins St Mand Rate 
#*MAND_ID 

#*!ntjns_typ id 
#*int_ins_cry arimp_cry_cd 

* inp_uda areajd 

* inp.jjda_.area typ 

* max_.dly_.rate 

* mnd strt dt 
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o CREATE DT 
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3.1 Coverage Engine Processes 


The coverage engine is a tuxedo service, which is called when information related to coverage 
types is required. The coverage engine is called internally by the rate search service if the 
specific vehicle category code is provided at the time of the call. The API for calling the coverage 
engine is exposed to the external systems so that it can also be called directly if user selects the 
vehicle category after the rate search call and then wishes to obtain the list of valid coverage 
types for the rental. 

3.1.1 Inputs 

P The following parameters are displayed in the order that they are needed. All parameters must be 
O passed. The mandatory/optional flags represent which information must be filled in for the 
coverage engine to return the correct coverage types and rates for the Retail SI business type. 


$Giwerage Engine Input P 



- • v.; •-• •• 



■ .. Input Pa&hWterW 







Standard Header 

The content of this header will be 
used for debugging, user test 
support, performance monitoring, 
tuning and error logging 

refer to standard header document 
for layout and population rules 

Mandatory 



All Clients 

VlM/ version string 

— Ill 

Identification string for this TUX 
interface 

FNJNSENGTV0001J/ERSION 

Mandatory 

char 

100 

TUX View 

res^tmsp 

Reservation Timestamp format 
YYYYMMDDHH24M! 

FNMEN_RESJTMPS 

Mandatory 

char 

13 

Client App 

-u4s 

c&jstnjd 

Station (Branch) ID of pickup 
location 

FNJ/IENCO_STNJD 

Mandatory 

char 

11 

Client App | 

co_cty 

Country Code of pickup location 

FN MEN CO CTY 

Mandatory 

char 

4 

Client App 

cojmsp 

Start Charges Timestamp 
format YYYYMMDDHH24MI 

FNMEN_COJ"MSP 

Mandatory 

char 

13 

Client App 

cijmsp 

End Charges Timestamp 
format YYYYMMDDHH24MI 

FN_MEN_CM"MSP 

Mandatory 

char 

13 

Client App 

bili_cyc!e 

Billing Cycle (Hourly - 'H\ or 
Calendar Day -C) 

FN_MEN_BILL_CYCLE 

Mandatory 

char 

1 

Client App 

Prodjype 

Product Type ('R'etail, ...) 

FN_MENJ 3 RODJTYP 

Mandatory 

char 

2 

Rate 
Engine 

cat cd 

Vehicle Code 

FN MEN CAT CD 

Mandatory 

char 

9 

Client App 

cat cd suffix 

Suffix vehicle category 

FN MEN CATCD_SFX 

Optional 

char 

5 

Client App 

Prod jjsg. status 

Product :j$aae Status 

FN MEN PROD USG STATUS 

Optional 

oh -if 



Prodjnstcd 

Coao 10 \>la:e 1 to a i:ar«cjter 
orodv. ct s.^tar ce 

FN_MEN.PRODJN3T.CC 

Qp'uonzl 

«(*^ 


Re is 

Prodjnstj/sr 

Verier n jrnfco' o; toe produce 

FN_MEN_PROD_NST- l JE R 

Opticrial 

long 



oorit id 


FM fvIEN COiMf :C 

Option*! 



went A^O 

enact! end «d 

Contract si Good ;*o.i \D 

=N WIcW ONTRCTL CND L 

Catena* 


4 

Ci.*r.t Avp 

insur ovrd ty;o 

7vse c ; Ov^r^dr 

-fc MEN HSUR OVRD TVP 





on tret? end null 

CQ~Ar£CUi%\ ZCfCU^OA Hull 

rtt MEN CKTRGTL CND NULl. 


Ions 


C"e»rc Anp 

insur ovrd mi-! 

ii &{i*c»* ^3 vZ»vejnO"? ^mlkI 

F*« 4 MEN ^SLR OVRD VJJ_ 

Gc:iOfci 

c "ar 


C: o-r A:o 

cLgracejinns 


FN jvi EM_ GRACE J\i? i*<:S 




C* er.t Avp 
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Coverage Engine Input Parameters - Version : Q&00 ~ Cont , > ^ v ; r > ^ . 


/ Technical 

Source of 

Input Parameter - 

' Notes < S ** 

\;s -FMLFieldName ' \ ; 


Type 

S/ze 

; Data 

Cur-' \ri 


C N MEN CJ*S tab 





co curr 


K>i MEN CO C\J*<H 





Areajds 

ListofUDA's 

FNJWEN_AREAJDS 

Optional 

char 

1000 

Rate 
Engine 



FN 3; ^ 2E3" „ ? ATS „.U£ BO 




r 

toy_profJd 

•_cyaftv P*c file ID 



VMS.! 




3.1.2 Outputs 

Coverage engine returns the list of coverage types and associated attributes for the specified 
rental. The output structure for this service and the associated details for the structure elements 
are described below. 

j*f The engine error field captures the error number associated with the service call. If engine error 
»{ field is anything other than '0' zero then the results of the output buffer are undefined. 

ft! 

□ The record count indicates the number of premium records returned from this call. The remaining 

j fields in the output list after this field have multiple occurrences as indicated by the record count 

W (rec_count). The coverage engine can return up to 50 records per call. 

The premium amount is expressed in terms of daily amount, weekly amount and monthly 
!j{ amount. Corresponding charge frequencies for each of the amount follows these. The charge 
m frequency is optimized based on the values defined for various charge amounts. 

Ql. The totals field is the total cost of selecting that coverage for this rental. 

Applicable status could be 'M'andatoiy, Tncluded, 'O'ptional or 4 D 5 o_not_offer. The client will 
need to do some processing based on the value for this flag. If the applicability status is 
Tncluded then the total cost for selecting the coverage is '0.00' zero. If the applicability status is 
'O'ptional for set of coverage types having same insurance super type then only one of those 
coverage types can be selected for this rental. 
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Output Parme^m* 

• 



" - ■. ■ 


SSfii 


dly__prm_amt 

Premium Amounts 

FN_1 EN_DLY_PRM_AMT 

Mandatory 

Double 

8 

CE 

_»t_ _ _ti. . 
nbr_dly 

Number of days to charge 

FNJEN_NBR_DLY 

Mandatory 

Long 

4 

CE 

wk_prm_amt 

Weekly Premium Amounts 

FNJENWKLY_PRM__AMT 

Mandatory 

Double 

8 

CE 

nbr_wkly 

Number of weeks to charge 

FNJEN_NBR_WKLY 

Mandatory 

Long 

4 

CE 

mt_prm_amt 

Monthly Premium Amounts 

FN J EN JWTLY_PRM_AMT 

Mandatory 

Double 

8 

CE 

nbrjntly 

Number of months to charge 

FNJEN_NBR_MTLY 

Mandatory 

Long 

4 

CE 

Stg_prm_amt 

Staggered Premium Amount for 
staaaered rate situations 

FN J EN_DLY_PRM_AMT2 

Optional 

Double 

8 

CE 

Nbr_stg 

Number of days 

FNJEN_NBRJDLY2 

Optional 

Long 

4 

CE 

ThresholcLdays 

Maximum number of days that can 
be charged at daily rate 

FNJEN_MAX_DAYS 

Optional 

Long 

4 

ce 

Mnd_dly_amt 

State Mandated Daily rate for this 
coveraae tvDe 

FNJENJVIND_DLY_AMT 

Optional 

Double 

8 

CE 

excs_dpst 

Excess Deposits 

FNJENJEXCS_DPST 

Mandatory 

Double 

8 j 

CE 

src curr 

Source Currencies 

FNJEN_SRC_CURR 

Mandatory 

Char 

4 

CE 

appk status 

— W£ i 

Applicable Statuses 

FNJENAPPL.STATUS 

Mandatory 

Char 

1 

CE 

rc%chgjyp 

Ret Charge Types 

FNJENJRCT_CHG_TYP 

Mandatory 

Char 

6 

CE 

tYRjd 
.. 

Type ID's 

FNJEN_TYPJD 

Mandatory 

Char 

9 

CE 

ty|glesc 

Type Descriptions 

FNJENJTYPJDESC 

Mandatory 

Char 

36 

CE 

cr^|ln1 

Condition Lines 1 

FN_JEN_CND_LN 1 

Mandatory 

Char 

76 

CE 

cnf4|ln2 

Condition Lines 2 

FN_IEN_CND_LN2 

Optional 

Char 

76 

CE 

urtMd_dy_rnt_amt 

Unbundled Daily Rental Amount 

FNJENJJNBLDJDYJRNT_AMT 

Mandatory 

Double 

8 

CE 

in%_superjype 

Insurance Super Types 

FNJENJNS_SUPER_TYPE 

Mandatory 

Char 

4 

CE 

pkjjgiuniqjd 

Package Unique ID's 

FN J EN_PKG JJ NIQJ D 

Optional 

Long 

4 

CE 


Full coverage flag , l\ x : ; 

F^EfsLFULL|CpV_frLG. 

Mandatory;, 

Char 


CE 

o^lmtanrit , ' — 

Coverage Limit Amount ; s : ^ - 

FNJEN_pOY_LW^A^ylT f 

Optional -7 4 

Double r 

8 V 

CE - 


j=f 3.1.3 Detailed Process Flow 


The Insurance Provision table combined with the Insurance Types table contains the information 
needed to return the proper coverage types and rates for the calling location. 

Each pickup location may not have the coverage type information set-up at the branch level. This 
requires that the coverage engine traverse through the 1 1 levels of rate hierarchy list for the 
specified pickup location starting with the lowest level. The traversal of the rate hierarchy is 
stopped, when one or more valid coverage types are found at a particular level 

Refer to the use case document on the UD A-Rate Hierarchy for additional details for the rate 
hierarchy. 

The first step is to locate the branch record within the STAJJDA table using the branch ID. 
Once located the additional information required for the hierarchy search would now be 
available. The STAJJDA table may contain a record for each level of the hierarchy that the 
branch is associated with. 
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The results of the above search will be combined with the following field group to find the list of 
applicable coverage types and charges for the specific rental: 

Product Type ('R'etail) = prod_type. 

Vehicle Category Code = cat__cd or 'ACAR\ 

Vehicle Suffix Code = cat_cd_suffix (North America Only). 

Pickup Date = co Jmsp (is between the start date and end date) 

Country Code = co_cty. 


Rate Engine 



Gather 
Search Info 


Search for 
Coverages 


Filter 
Coverages 


State 
Overrides 


Optimize 
Coverages 


Create 
Output List 


Start 


Input Structure 


Minimum Parameters 
Reservation Timsstamp 
Checkout location (D 
Country Code 
Checkout Timestamp 
Calendar/24 Hour Indicator 
Product Type 
Vehicle Category 
Vehicle Suffix 


Retrieve info 
from STAJJDA 
table 


i 
i 


Return Search 
Criteria 


Get Applicable 
Insurances 


Return List of Coverages 


Traverse hierarchy, from lowest 
(Branch) to highest (Company), 
to find match. Once match is 
found it will stop at that level 


Remove Duplicate and non-valid items from list 


Return Filtered List 


Output Structure 


Up to SO 

Record Count 
PrerriumiD's 
Daily Premum Amount 
Number of Days 
Weekly Premium Amount 
Number of Weeks 
Monthly Prenrium Amount 
Number of Months 
Total Charges 
Deductible Amount 
Source Currency 
Applicable Statuses 
RCT Charge Types 
Type ID's 
Type Descriptions 
Condition Line 1 
Condition Line 2 
Unbrd Daily Rental Amount 
Super Types 

Package ID's 

Return 


Loop through list of 
coverages to 
remove Duplicates. 


Find rf anv Co verage Types have State Mandated Limits 


Return List 


Loop thru list 
to locate State 
Charges 


Determine Best Charges for Each item in list 


Return Optimized List 


Loop through each Hem 
to determine optimized 
charge frequency. 


Move optimized list to the output structure 


Return Riled Output structure 


ft/love remaining 
items to output 
structure 
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At the lowest level, the search for valid coverage types would proceed as follows(North America 
Only): 

• Vehicle Category Code + Suffix 

• For this Product Type 

• In this Country 

• Within the specified date range 

If not found then the search would be (This would be the European starting point): 

• Vehicle Category Code 

• For this Product Type 

• hi this Country 

• Within the specified date range 

|»i If still not found then the search would become: 

Q • 'ACAR' 

Q • For this Product Type 

J*! • In this Country 

S • Within the Specified Date Range 

fjj If still not found then the next level of the UDA hierarchy will be searched starting again with the 
a first search and proceeding with this process until a match is found. 

PJ If no match is found, after the hierarchy traversal, the output list will be returned with a record 
count of 0. 

01 

f r l The engine will then remove all duplicates and non-available coverage types through a filtering 
? " process. This process will use the car class hierarchy to eliminate any duplicates. The next step is 
to look for coverage types marked as 'included' or 'mandatory'. If found it will eliminate any 
others from the list with the same super type. This will be done in the following manner. Looping 
through the valid records in this sort order: 

• Vehicle Car Class with Suffix 

• Vehicle Car Class 

• ACAR 

Each subsequent record that is still marked as valid whose coverage type is the same as the 
current record will be marked as invalid. The final step will be to check any packages that have 
been created to ensure that no conflicts exist there. 
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After filtering, a check will be made to determine if any state mandated limits exist for specific 
coverage types. By determining the state code from the STA JJDA table each valid coverage 
super type will be checked to see if any limits need to be applied. If a super type has not been 
defined then the coverage type itself will be used to check for a match. If found the amount will 
be updated in the output list as a separate field that can be referenced by the user forms. If the 
daily rate is greater than the state mandated rate the daily rate will be changed to reflect the state 
mandated rate. 


hi 
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The output records returned would be: 


Field 

Value(s) 

Engine Error 

0 

Record Count 

3 

Premium ID'S 

OA \ 

£0 


Daily Premium Amounts 


n 
u 


Number of Daily Premiums 

7 

A 
U 

u 

Weekly Premium Amounts 

%o ^n 

u 

0^ QQ 

Number of Weekly 
Premiums 

n 
u 

u 

1 

Monthly Premium Amounts 

1^0 on 

n 

U 


Number of Monthly 
Premiums 

n 
u 

u 

u 

Staggered Premium 
Amount 

n nn 
u.uu 

n nn 
u.uu 

n nn 
u.uu 

Number Staggered 

u 

u 

u 

Mandated Dailv Rate 

n nn 
u.uu 

n nn 
u.uu 

n nn 
u.uu 

Excess Deposits 

1^0 nn 

okh nn 

n nn 

u.uu 

Source Currencies 

US 

W W 

US 

US 

WW 

Aoolicable Statuses 

0 

1 

O 

Charae Types 

00007 

00010 

00006 

Type ID's 

A.C. 

PAI 

SLP1 

CDW1 

Type Descriptions 

Personal ... 

Supplemental... 

Collision... 

Condition Line 1 

Personal ... 

Supplemental... 

Collision... 

Condition Line 2 

Null 

Null 

Null 

Unbundled Daily Amount 

0 

3.99 

0 

Super Types 

PAI 

SLP 

CDW 

Package ID'S 

0 

0 

0 

. Full Covera^Ela^fbl^M 




Coverage Limit Amount 
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The output records returned would be: 


Field 

Value(s) 

Engine Error 

0 

Record Count 

4 

Premium iD's 

34 

32 

31 

33 

Daily Premium Amounts 

5.99 

4.50 

3.00 

4.50 

Number of Daily Premiums 

3 

3 

3 

3 

Weekly Premium Amounts 

25.99 

32.50 

21.99 

32.50 

Number of Weekly 

0 

0 

0 

0 

Premiums 





Monthly Premium Amounts 

55.99 

130.00 

47.99 

130.00 

Number of Monthly 

0 

0 

0 

0 

Premiums 





Staggered Premium 

0.00 

0.00 

0.00 

0.00 

Amount 





Number Staggered 

0 

0 

0 

0 

Mandated Daily Rate 

0.00 

0.00 

0.00 

0.00 

Excess Deposits 

0.00 

100.00 

250.00 

100.00 

Source Currencies 

US 

us 

US 

US 

Applicable Statuses 

0 

0 

0 

O 

Charge Types 

00006 

00007 

00010 

00010 

Type ID's 

CDW1 

PAI 

SLP1 

SLP2 

Type Descriptions 

Collision 

Personal 

Supplem 

Supplem 



ental... 

ental... 

Condition Line 1 

Collision 

Personal 

Supplem 

Supplem 




ental... 

ental... 

Condition Line 2 

Null 

Null 

Null 

Null 

Unbundled Daily Amount 

0 

0 

0 

0 

Super Types 

CDW 

PAI 

SLP 

SLP 

Package ID's 

0 

0 

0 

0 






Coverage 'Limit Amounts ? 
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GA 
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ST 
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ft 
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The output records returned would be: 


Field 

Value(s) 

Engine Error 

0 

Record Count 

3 

Premium ID'S 

12 

11 

13 

Daily Premium Amounts 

5.99 

3.99 

3.99 

Number of Daily Premiums 

1 

1 

1 

Weekly Premium Amounts 

25.99 

26.99 

21.99 

Number of Weekly 
Premiums 

1 

1 

1 

Monthly Premium Amounts 

55.99 

110.99 

47.99 

Number of Monthly 
Premiums 

0 

0 

0 

Staggered Premium 
Amount 

0.00 

0.00 

0.00 

Number Staggered 

0 

0 

0 

Mandated Daily Rate 

0.00 

3.99 

0.00 

Excess Deposits 

0 

500.00 

250.00 

Source Currencies 

us 

us 

US 

Applicable Statuses 1 

0 

M 

O 

Charge Types 

00006 

00007 

00010 

Type ID'S 

CDW1 

PAI 

SLP1 

Type Descriptions 

Collision 

Personal 

Supplemental ... 

Condition Line 1 

Collision 

Personal 

Supplemental ... 

Condition Line 2 

Null 

Null 

Null 

Unbundled Daily Amount 

0 

0 

0 

Super Types 

CDW 

PAI 

SLP 

Package ID's 

0 

0 

0 





Coverage limit £tw»fiit^ 


IW§5# 
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The output records returned would be: 


s 

III 


i«3s 


5 - 
pip 

m 


rieia 

Value(s) 

Engine Error 

0 

Record Count 

4 

Premium id s 

41 

42 

43 

44 

Daily Premium Amounts 

2.00 

1.50 

5.99 

3.99 

Number of Daily Premiums 

3 

3 

4 

4 

Weekly Premium Amounts 

0.00 

0.0 

35.99 

28.99 

Number of Weekly 

0 

0 

0 

0 

Premiums 





Monthly Premium Amounts 

0.00 

0.00 

100.99 

98.99 

Number of Monthly 

0 

0 

0 

0 

Premiums 





Staggered Premium 

1.00 

1.00 

0.00 

0.00 

Amount 





Number Staggered 

1 

1 

0 

0 

Threshold Days 

3 

3 

0 

0 

Mandated Daily Rate 

0.00 

0.00 

0.00 

0.00 

Excess Deposits 

0.00 

0.00 

150.00 

0.00 

Source Currencies 

US 

us 

us 

us 

Applicable Statuses 

0 

0 

D 

D 

Charge Types 

00007 

00010 

00011 

00006 

Type ID'S 

PAI 

PEC 

SLP 

CDW 

Type Descriptions 

Personal 

Personal 

Suppleme 

Collision 




ntal... 


Condition Line i 

Personal 

Personal 

Suppleme 

Collision 




ntal... 


Condition Line 2 

Null 

Null 

Null 

Null 

Unbundled Daily Amount 

0 

0 

0 

0 

Super Types 

PAI 

PEC 

SLP 

CDW 

Package ID'S 

0 

0 

0 

0 

Full Cc^er^fila&^M! 





Coverage Limit Amount •> 

0.00 


o oo * " ^ 

0.00 
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4.1 Risks 

4.2 Assumptions 

4.3 Issues 

The following issues, broken out by major category, have been identified as part of Iteration 2. 
|4.3.1 Staggered Rates 


(S)o you offer Staggered rates for additional products like coverage types . Currently New York 
Charges PAI at $3.50 for the first day and a decreased rate after the first day. 


flWhen CDW coverage is included in the rate, is it always the highest liability limit that can be offered 


hRE: Closed during Detail Design Review. 
4.3,3 Zero as a Valid Value 

During the detailed design review it was indicated that zero could be a valid value for any of the 
charge amounts. VRS currently uses zero in charge amount to indicate the presence of null. We need 
to agree on another convention for VRS engines to communicate presence of null. 

RE: Closed during Detail Design Review. 


JyE: This is being created as a new gap, that will be included in iteration 2. 


E 8 a 

3.3.2 CDW 



a branch? 
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System 

{insurance provisions are defined for existing Insurance Type Ids.} 


Q 


w 


W 0 


SiA 

? - Acton 

1*1 


5 


-End7 


-End2 


-End4 


«exte nds» 


-End6 



«exte nds» 



-End9 


«exte nds» 


/laintainlnsuranceApplicabr 
[ HtyByProdcutTypeByLocation ] 
Hierarchy 


WaintainStateMandatedlA 
, imitsForlnsuranceTypes, 


-End13 


O 



Actor2 
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1 Introduction 

Overview 

The purpose of this document is to provide detailed design specifications of how 
the ECARS SI Retail default rates are mapped and converted to the VRS data 
model for iteration 2. 

Iteration Dependencies 

No Cross Dependencies for this Iteration. 
Environment 

The Unix platform will be used for all SI data extracts for conversion purposes. 
Data will be extracted from the Enterprise Oracle instance and converted into the 
VRS data model. Pro*C programs and, where appropriate; SQL Loader will be 
used to read/write and process the data extracts. 

For low volume data loads spreadsheets will be used to obtain the appropriate 
data from ERAC. 

si 

5 3 

ssssi 

|1j 2 Design Specifications for functional areas: 

« ? 2. 1 Functional Area: Product Types 

us 

!■* 

2.1.1 Data Transformation Rules 

One product type will be created for each line of business having it's own set of 
products and rates. For Iteration 2 the retail (R) product type will be the primary 
focus. Product types will be set up prior to the conversion process. Perot Systems 
will provide suggested values for the retail product type entry, and ERAC will be 
responsible for validating the suggested data set up. 

For Iteration 3 we have added a Special Retail product type (S) for the conversion 
of the SI Retail business with a RateTvpe of SPL. 

2.1.2 Data Selection Criteria 

N/A 

2.1.3 Source and Target Table Impacts 


Source Tables 

Target Tables 

BUS TYP 

PROD TYPS 


114 


1.1 


1.2 


1.3 


Vij 

fil 
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2.1.4 Detailed Table / Column Mapping 

N/A 

2.1.5 Data Dependencies 


f Prod Tvps 

#*PROD_TYP_CD 
* PRODJTYP DESC 
v* BILL CYCL IND 


2.1.6 Manual Conversion 

Two Product Types will be created manually by Perot Systems. One for SI retail 
conversion and one for UM Rates (NatRes). Both entries will use a 24 hour 
billing cycle. The entries will be created as shown below. 


Product Type 

Product Type Description 

Billing Cycle Indicator 

R 

Standard Retail Product Type 

H 

s 




2.1.7 Assumptions 

N/A 

2.1.8 Issues 

N/A 

2.1.9 Data Volumetrics 

2 

2.1.10 Data Validation Criteria 

N/A 
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2.2 Functional Area: Product Families 
2.2.1 Data Transformation Rules 


Product families will be set up prior to the conversion process. Perot Systems will 
provide suggested values for the retail product family entry, and ERAC will be 
responsible for validating the suggested data set up and verifying that it meets their 
business needs. 

2.2.2 Data Selection Criteria 

N/A 


If 

0 

m 
O 
H 

hi 

■J IP'S' 


n 

MB? 

Easr. 


2.2.3 Source and Target Table Impacts 


Source Tables 

Target Tables 

Data provided by ERAC 

PRODS 


2.2.4 Detailed Table / Column Mapping 

N/A 


2.2.5 Data Dependencies 

Prior to creating product families (PRODS) the product types table 
(PRODJTYPS) must be populated. 


f Prods 

rPRODJD 
* PRODJDESC 
PRT PRODTYP_CD 


>0 — PRD_OF« 


Prod Tvds 

#*PRODJYP_CD 
* PRODJTYP DESC 
C B!LL_CYCL IND 


2.2.6 Manual Conversion 

Two ProductFamilies will be created by Perot Systems for the SI retail 
conversion, i.e. one for Retail and one for Special Retail. 

The entries will be created as shown below. 


Product Type 

Product Family 

Product Family Description 

R 

RTLM 

Retail Standard Rates 

1 

RTS 
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2.2.7 Assumptions 

Product family RTLM is for SI retail conversion (Iteration 2). 

Product family RTS is for SI retail conversion, but for SPL rates (Iteration 3). 

Product family RTLM will also be used for NATRES UM productdteration 31 

2.2.8 Issues 

N/A 

2.2.9 Data Volumetrics 

2 

2.2.10 Data Validation Criteria 

N/A 
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2. J Functional Area: Product Instance 

2.3.1 Data Transformation Rules 

Product instances will be set up prior to the conversion process. Perot Systems 
will provide suggested values for the retail product instance entries. Enterprise 
will be responsible for validating the suggested data set up and verifying that it 
meets their business needs. 

2.3.2 Data Selection Criteria 

N/A 

2.3.3 Source and Target Table Impacts 


Source Tables 

Target Tables 

Data provided by ERAC 

PROD INSTS 


2.3.4 Detailed Table / Column Mapping 

N/A 


2 3.5 Data Dependencies 

Prior to creating product instances (PRODJNSTS) the product types table 
(PROD_TYPS) and the product family table (PRODS) must be populated. 
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s 


H 


ij"**" 

M S 

SIS 


5 53: 

u 


r Prods ^ 

#*PROD ID 

* PROD_DESC 

v ^P RT_P R O D_TYP„C D ^ 

I 

O 

* x 

Prod Insts 

#*PRODJNST_CD 
PRD_PRODJD 
C R Y_AR IM P_C RY_C D 
PRODJNST.DESC 
CREATE USER ID 
CREATE_DT 
0 CUR CURR_CD 
0 VER_NBR 

0 AiRLINE_TICKET_REQD IN D 

0 AUTH_STAT 

0 AUTO.RECMPT RT 

o BEST_RT_FLG 

o COMPANY CD 

0 COM_FLG 

o CO_STRT_DT 

o FREE_VHCL__COLL 

o FREE_VHCL__DLVR 

0 FUEL_INCL_FLG 

0 GTEE_RT_IND 

o GUAR_DAYS_NBR 

0 max_com rt 
0 one way only 
0 prefLchanjnd 

o RES STRT_DT 

0 RT_BASE_UNtT_CD 

0 SEC RATE_IND 

OAUTH DT 

0 AUTH_USR 

0 CO_END_DT 

o CPL_PLANJD 

o CRS_STAT 

o DBG_BNDJD 

o DSCNT FUG 

0 EXRJTYP_CD 

0 FF TVL_FLG 

0 MAX_DSCNT_RT 

oMIN_RNT_DAY FOR_DOM 

o MIN_RNT_DAY FOR INT 

o PRLRANK IND 

o PROD_USG STAT 

o RES_CHN G_FLG 

0 RES_END_DT 

0 SALE_TX_INCL_FLG 

O SELF_SVC IND 

0 UNBLD_FUEL_RENT_AMT 

0 SCHG INCL_FLG 

o LAST_UPDT_USER_iD 

0 LAST_UPDT_DT 

o IPC_CPL_PLANJD 


*0— PRD_OF- 


r Prod.Typs 

#*PROD TYP_CD 
* PROD TYP DESC 


23.6 Manual Conversion 

Four Product Instances will be manually created by Perot Systems for the SI retail 
conversion. These four entries create products to be used for standard SI local 
market retail rates. 

The product instances created will be given generic names. There is no 
"intelligence" behind the name of the product. In cases where only one SI retail 
rate is active at a given location for a specific point in time, product RTLSI1 will 
be used by the conversion process. In the event more than one retail rate plan is 
active at a given location, products RTLSI2 through RTLSI4 will be used as 
needed. 
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In addition to four retail products two additional products for SI Special Retail 
rates and one product for the UM-rates (NatRes) will be created 
There is no intelligence behind these product codes. 

The product instance entries will be created as shown below. 


issh 
s 

111 

m 

H 

id 


53 R 

m 
m 


JT I UliULv.1 

Code 

JL lUUUVi I llo Kill V V 

Description 

Product 

JL X UUUVl 

r amity 
Code 

Cfmntrv 

Create 
Date 

RTLMl 

Standard Local Market Retail 1 

RTLM 

US 

Current Date 

RTLM2 

Standard Local Market Retail 2 

RTLM 

US 

Current Date 

RTLM3 

Standard Local Market Retail 3 

RTLM 

US 

Current Date 

RTLM4 

Standard Local Market Retail 4 

RTLM 

US 

Current Date 

RTLM5 

Standard Local Market Retail 5 

RTLM 

us 

Current Date 

RTLM6 

Standard Local Market Retail 6 

RTLM 

us 

Current Date 

RTLM7 

Standard Local Market Retail 7 

RTLM 

us 

Current Date 

RTLM8 

Standard Local Market Retail 8 

RTLM 

us 

Current Date 

RTLCIN 

Standard Local Market Retail 
Inactive 

RTLM 

us 

Current Date 









m 

Current Date 

wist 
















Create 
Operator 

Tax Included 
Flag 

Surcharge 
Included Flag 

Refueling Included 
Flag 

CONVERSION 

N 

N 

N 

CONVERSION 

N 

N 

N ■ 

CONVERSION 

N 

N 

N 

CONVERSION 

N 

N 

N 

CONVERSION 

N 

N 

N 

CONVERSION 

N 

N 

N 

CONVERSION 

N 

N 

N 

CONVERSION 

N 

N 

N 

CONVERSION 

N 

N 

N 






8 


H 


i 








1 « 




2.3.7 Assumptions 

SI Conversion (Iteration 2) 

Special retail products will not be created for any specific purpose (i.e. unlimited 
miles, limited miles high, etc). The standard retail rates as they exist in SI today 
can be either limited miles, unlimited miles, or unlimited miles for selected 
vehicle categories and limited miles for others. Regardless of the mileage limits of 
a particular rate plan, they will be converted under a common product instance. If 
the rate is inactive the details will be tied to the RTLML 
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SI Conversion Special Rates (Iteration 3) 

Two product codes will be used for Special Retail rates. 


NatRes Conversion {Iteration 3) 

Since there can only be one UMrate header active at any given point in time, for 
a particular branch, there is no need to have more then one product instance. 
There is no concept of Inactive products in UM since no History will be brought 
over. 


2.3.8 


Issues 

N/A 



2.3.9 


2.3.10 Data Validation Criteria 

N/A 


Data Volumetrics 

8 


ill 
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2.4 Functional Area: Rate Qualifier 


2.4.1 Data Transformation Rules 

One Rate Qualifier will be created manually for the SI Special Rates (RTS) 

Below are the Special Rate rules represented in the RateQual Table 
(RNTJDRTNJ3NDS) 


CoStrtDay 

CoFrom 

CoEndDay 

CoUpto 

CiDayOfWk 

Friday 

12:00 

Sunday 

10:00 

Monday 


2.4.2 Data Selection Criteria 

N/A 


pi 

5 BMP 
5 - 5 


111 
IP 


2,4.3 Source and Target Table Impacts 


Source Tables 

Target Tables 

N/A 

RNT DRTN BNDS 


2.4.4 Detailed Table / Column Mapping 

N/A 

2.4.5 Data Dependencies 

None 


2.4.6 Manual Conversion 

One RateQual will be created for association with Special Product to 
accommodate iteration 3 testing. These quals will be created manually by ERAC 
when the system goes live. 

2.4.7 Assumptions 

2.4.8 Issues 


2.4.9 Data Volumetrics 
1 

2.4.10 Data Validation Criteria 

N/A 
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25 Functional Area: Rates 


2.5.1 SI Rates 


2.5, 1 .4 Data Transformation Rules 

The ECARS conversion retrieval will consist of a number of logical retrieval 
processes at each Hierarchy level. The table below represents some volumetrics 
from the ECARS database. For a full list refer to section 2.5,10. These 
volumetrics are based upon a database refresh received by PSC on September 17 
2001, and represent five of the eighteen ECARS machines. 


h 

f 



Ecars Table 


Total 'R'etail Rows 


Active 'R'etail Rows 


Deleted f R r etail -Rows 


Inactive 'R'etail Rows 

^Branch 


BRJDFLT 


212 


65 


103 


44 

iPhone Exchange 

•a — 

AREA_XCHNGJDFLT 

1 

0 

1 

0 

y 

f hone Area 

Not Available 





i£ip Code 

ZIP CDE DFLT 

1 

1 

0 

0 


?High Zip Code 

Not Available 





l s 

City 

Not Available 





sArea 

AREA_DFLT 

122 

47 

57 

18 

8; 

I 15 
p 

gi 
jl 

^State 

STJDFLT 

9 

2 

7 

0 

. Sub Region 

Not Available 





..Region 

REGN_DFLT 

19 

10 

6 

3 

.Group 

GRP_DFLT 

21 

12 

8 

1 







iTotal 


385 

137 

182 

66 ! 


3 a 


2.5.1.5 Data Selection Criteria 

This section describes the retrieval from the ECARS tables and which fields are 
retained and used by the VRS population. 

Ecars Retrieval 

BR _DFLT/ AREA JCCHNGJDFLT/ ZIP J0DEJ)FLT/ 'AREA JDFLT / STJDFLT / 
REGN_DFLT / GRPJ>FLT 

For all hierarchy levels the entry point for the conversion process will be one of the 
xxxxxJDVLT tables. This will allow us to retrieve all the rates and other appropriate 
information from the ECARS tables based upon their availability. 

The selection criteria is as follow: 

- The rows marked with a BusinessType of 'Retail will be retrieved. 

- The rows with a RecordStatusCode equal to <null> or Tractive will be retrieved. 
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For all hierarchy tables the fields BusinessType and DefaultNumber will be retained 
and used to retrieve the corresponding data from the DFLT table. 

For the BR_DFLT table the fields Groupld and Branchld will be retained for VRS 
population. 

For the AREAJZCHNGJDFLT table the fields AreaCode and AreaExchangeNbr will 
be retained for VRS population. 

For the ZIPjCDE_DFLT table the field ZipCode will be retained for VRS population. 

For the AREA_DFLT table the fields RegionCode and AreaCode will be retained for 
VRS population. 

For the STJDFLT table the field StateCode will be retained for VRS population. 

For the REGN_DFLT table the fields RegionCode will be retained for VRS 
population. 

For the GRP_DFLT table the fields Groupld will be retained for VRS population. 
DFLT 

Using the BusinessType and DefaultNumber as obtained through the xxxxxJDFLT 
retrieval, all appropriate rows will be retrieved from the DFLT table. 
Further selection criteria are also applied: 

- The rows with a RecordStatusCode equal to <null> or Tnactive will be retrieved. 

- The fields StartDate and EndDate will be retained for examination/usage at a later 
stage. 

DFLTJIA TE_PLAN 
Using the BusinessType and DefaultNumber all appropriate rows will be retrieved 
from the DFLT_RATE_PLAN table. 
Further selection criteria are also applied: 

- The rows with a RecordStatusCode equal to <null> or Tnactive will be retrieved 

- The fields RatePlanSeqNbr and Groupld will be retained and used to retrieve the 
corresponding data from the RATEJPLAN table. 

RATE_PLAN 

Using the RatePlanSeqNbr and Groupld as obtained through the 
DFLTJIATE JPLAN retrieval, all appropriate rows will be retrieved from the 
RATEJPLAN table. 
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Further selection criteria are also applied: 

- The rows with a RecordStatusCode equal to <null> or 'Inactive will be retrieved 

- BusinessTypeCode may be null or must match the BusinessTypeCode from the 
DFLTJRATE_PLAN table. 

- The fields RatePlanDiscription, StartDate and EndDate will be retained for 
examination/usage at a later stage. 

PLANJJNITJUTE 
Using the Groupld and RatePlanSeqNbr as obtained through the RATE JPLAN 
retrieval, all appropriate rows will be retrieved from the PLANJJNITJUTE table. 
Further selection criteria are also applied: 

- The rows with a RecordStatusCode equal to <null> or Tnactive will be retrieved 
, , - Only the rows with a RateTyp^Code in Hourly,Daily 5 Weekly s Monthly and 

!^ Special will be retrieved, thus ignoring RNT t PKG & PCT 

j! J - The fields CarClassId, CarClassSuffixId, RateTypeCode, RateAmt, 

fij FreeMilesLimit, UnlimitedMileageFlag, ExcessMileageCharge, 

StartKeyDateTime and EndDate will be retained for examination/usage at a later 
Q stage. 
H 

W RATEJYP 

f Using the RateTypeCode as obtained through the PLAN JJNIT_RATE retrieval, all 

j|J* rate types are retrieved. These RateTypes will be used by the VRS population logic to 

J populate the appropriate amount column and mileage column. 

S REMARKS 

p The Rates Conversion program will provide a mechanism, through Conversion Temp 

Tables (CONVJPROD JCREF) where the General Conditions, Coverage and 
Additional Product conversion programs can determine to which Productlnstance a 
RatePlan has been setup with and which UserDefinedArea had been used. 

If the occasion arises where the whole retrieval process cannot be satisfied, eg: if a 
RecordStatusCode in one off the ECARS tables has been flagged as delete. The 
conversion process will not convert this row but output the appropriate information to 
a NotConverted file. This NotConverted mechanism will be driven through a 
command line argument, allowing for it to be switched on or off. The default will be 
off. 

The conversion process will also produce a flat file containing a list of orphan 
rateplans, which were identified as not being used at any level of the hierarchy. 
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2.5.1.6 Source and Target Table Impacts 


source lables 

larget lables 

r>K DrLl 


AKbA XCHNCj DrLl 


ZIP COUb DrLl 


AKbA DrLl 


SI DrLl 


KbuJN DrLl 


ORr DrLl 


DrLl 


TVTT T Tl A HPT"* TIT A \T 

DFLT RATE PLAN 


KAIL rLAiN 


PLAN UNIT RATE 


RATE TYP 



RATES HEADER 


RATE DETAIL USAGES 


RATE DETAILS 


PROD AVLS 




CONV PROD XREF 
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2.5.1.8 Data Dependencies 

As the information, provided by the ECARS database, only allows us to populate 
certain tables and columns of the VRS Rates Model, a number of tables and fields 
will be populated with defaults. 

Pre-dependencies 

In order to populate rates and the appropriate supporting data, a number of tasks 
must have happened already: 

- Product Types have to be pre-populated (vrs.prodtyps) 

- Product Families have to be pre-populated (vrs.prods) 

- Product Instance(s) for conversion have to be pre-populated (vrs.prod_insts) as 
well as their Product Availability (vrs.prod_avls). 

- A RateQual has to be pre-populated (ws.rntj)rtnj3nds) for SPL (Special) 
Rates 

- User Defined Areas have to be pre-populated (vrs.usr_dfnd_areas / vrs.stajjda) 


2.5.1 .9 Manual Conversion 

N/A 

2.5.1.10 Assumptions 

• RatePlans with no rates will not be converted 

• RatePlans with rates and not associated to one of the hierarchies will not be 
converted 

• In the case where it was determined that a RatePlan/Rate was shared 
between hierarchies, the VRS.RatesHeader will be tied to the appropriate 
UserDefinedArea at the highest Hierarchy Level, i.e. starting from 
AYT_GRP down to ATYJ3R. 

• No specific rate qualifications will be established for retail products, with 
the exception of one RateQual for SPL (Special) Rates. Where the occasion 
exists where the default conversion RateQual does not meet the typical SPL 
(Special) business policies, Enterprise will have to create anew RateQual 
manually, and re-tied the non-standard RateQual to the RatesHeader. 

• Since inactive Rates (rec_stat_cde = T) will only be available for 
referencing, i.e. not to be quoted back to the customer, these will be tied to 
the Inactive Product. 

• Default weekend special qualification association record will be created as 
part of the Iteration 3 conversion, ERAC will be responsible for manual 
creation post implementation . 

2.5.1.11 Issues 

N/A 
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2.5, L12 Data Volumetrics 

Will be provided as a part of the conversion deliverable at the end of iteration 3. 

2.5.1.13 Data Validation Criteria 

Data validation will happen through SQL scripts, RatesEngine test harness and 
investigating the NotConverted and log files. ERAC will be responsible for 
investigating the exceptions and making corrections as required on AS/400 and 
re-converting into Oracle. 
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2.5.2 NatRes Rates 

We assume that a Flat File representation of the two main NatRes tables (i.e. 
NRARates & NRXRates) will be made available in our Oracle Conversion DB 
Instance. 

The current NRARates & NRXRates data used for analysis are partial extracts. 
A new extract will be required prior to conversion. 

2.5.2.4 Data Transformation Rules 

The NatRes conversion retrieval will consist of one Retrieval process. NatRes 
rates are only applicable for one hierarchy level Branch Level. The table below 
shows some volumetrics, the content of the NatRes tables were provided by 
Enterprise on July 23 2001. 


*'I Level 

NatRes Table 

Total Rows 

# of Rows with 
EffRateDate >= 
31IUL01 All Retail 

# oj Rows with 
DscntStopDate < 31JUL01 
AllBid 

# of Rows with 
ExcBidRateFlag = B 

I -J 



{ Branch 

NRARATES 

331,331 

319,365 

N/A 

N/A 


NRXRATES 

71,712 

N/A 

29 

98 


Data Selection Criteria 

This section describes the retrieval from the NATRES tables (NRXRATES & 
NRARATES). For Iteration 3 these two tables, with their data, will be made 
available within an oracle instance. In future iterations these tables will be 
updated and used as the UM Bridge between the AS400 and the VRS system. 

NatRes Retrieval 

The entry point for the conversion process will be the NRXRates table. 

Following filters are in place on retrieving the NRXRates data 

- Rows with an ExceptionBidRateFlag of ( B 3 will be retrieved. 

- Rows with NRARates.DateofRate between NRXRates.DscntStartDate and 
NRXRates.DscntStop.Date 

- Rows with a Status of V 9 and 'R' will be retrieved 

Using the Groupld, Branchld, Rate category, DiscountStartDate, 
DiscountStopDate and CarType from the NRXRates, the rate data will be 
retrieved from the NRARates table. In addition to the join criteria, a filter is in 
place to only consider the NRARates rows which have a RateCategory of f R 
Following fields will be retained for VRS transformation/population: 
NRXRates 

Groupld, Branchld, CarType, DailyMileage, DailyUnlimitedMiles, 
DailyExcessMileage, WeeklyMileage, WeeklyUnlimitedMileage, 


2.5.2.5 


m s 


&11 
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WeeklyExcessMileage, Monthly Mileage, MonthlyllnlimitedMiles, 
MonthlyExcessMileage. 
NRARates 

DateOfRate, DaylRentalPrice, DaylRentalPrice, Day3RentalPrice } 
Day4RentalPrice, WeeklyRentalPrice, MonthlyRentalPrice. 

2.5.2.6 Source and Target Table Impacts 


Source Tables 

Target Tables 

NRXRATES 


NRARATES 



RATES HEADER 


RATE DETAIL USAGES 


RATE DETAILS 


PROD AVLS 
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2.5-2.8 Data Dependencies 

As the information, provided by the NatRes database only allows us to populate 
certain tables and columns of the VRS Rates Model, a number of tables and fields 
will be populated with defaults 

Pre~dependencies 

In order to populate rates and the appropriate supporting data, a number of tasks 
must have happened already: 

- Product Types have to be pre-populated (ws.prodjtyps) 

- Product Families have to be pre-populated (vrs.prods) 

- Product Instance RTLUM, for NatRes conversion has to be pre-populated 
(VRS.prodjnsts) as well as their Product Availability (vrs.prod_avls) 

2.5.2.9 Manual Conversion 

N/A 


2.5.2.10 Assumptions 

• For the First Cut Conversion the NRARates & NRXRates tables will be made 


§ available in Oracle equivalent tables within a Conversion DB Instance 

: 4 • NatRes rates only represent Vehicle Rates, i.e. Coverage Rates, Additional 

jj Product Rates, Messages and rules will not be converted (The NR042P and SI- 

TX07 files are out of scope for the VRS Conversion). 
■ • There will be no conversion of History, only rates effective as of the 
conversion date will be converted. 
• All NatRes rates are at Branch Level, i.e. no Hierarchy logic on NatRes 


Si 

» , 

gtS&i 


p conversion. 

1*1 « 


All NatRes rates will be tied to one Product Code (i.e. RTLUM) 
RateCategory 'Retail is the only RateCategory which will be converted for 
Iteration 3. 

Rates are effective for one-day only, therefore (with the exception of 
duplicates), the VRS CheckOutStart and End Dates will be timestamped with 
'000000' and '235959' respectively, and will only be available for that one 
day. 

The VRS Car Suffix will be set to '**', since no suffix is available from 
NatRes. 

PeopleSoft cross reference keys will have to exist for all NatRes locations. 
ExtraHour, ExtraDay and ExtraWeek rates will not be populated as the 
application design will be addressing them in the next iteration. 
Certain NatRes Day 1/2/3/4 Rates or Weekly & Monthly Rates may not be 
available. The conversion process will not interpret the population rules of 
these and will just populate what has been provided. The responsibility of 
interpreting the values is within the scope of the Pricing Engine. 
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• Using the NRX entry point for the retrieval process resulted in the selection of 
14, 870 records. 

2.5.2,11 Issues 

• There is no requirement currently to classify a rate as Open, Restricted or 
Closed. This is outside the scope of the current project and might be 
addressed through the availability engine. 

• Do we need to convert any NRA rates that cannot be joined with NRX 
rates? ERAC has stated that dormant rates in NRA can be reactivated at a 
later stage. Laurie Bowen from ERAC will validate. 

• Our current assumption is that we will not be converting any rules 
associated with NRA or NRX rates since NRX rates are not being 
converted. ERAC has stated that deposit, miscellaneous and guarantee 
rules should be converted as messages. An issue was opened to address 

U this with ERAC. 

o 

ni 

IW 

O 2.5.2.12 Data Volumetrics 

W The following table volumetrics are the result of the current data extract from five UM 

r . locations: 


!1 


Source Tables 

Target Tables 

Number of 
Rows 

Comments 

NRXRATES(where 
Exception/Bid Rate 
flag = 'B' 


98 

Retail only 

NRARATES 


319,365 

Retail only 


RATES HEADER 

5 



RATE DETAIL USAGES 

5 



RATE DETAILS 

14,870 

Not anticipating 
duplicates. 


2.5.2.13 Data Validation Criteria 

Data validation will happen through SQL scripts, RatesEngine test harness and 
investigating the NotConverted and log files. There will also an attribute on the 
Staging NatRes tables in the Oracle DB which will represent multiple statuses. 
ERAC will be responsible for investigating the exceptions and making corrections 
as required on AS/400 and re-converting into Oracle. 
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2. 6 Functional Area: Equipment 

2.6.1 Data Transformation Rules 

N/A 

2.6.2 Data Selection Criteria 

N/A 

2.63 Source and Target Table Impacts 


ill 

w 
SI 


I* 
nil 

I ; 


Source Tables 

Target Tables 

PLN ADDTL PROD RATE 
ADDL_PROD_TYP 

EQP ITEM TYPS 
EQP CHGS 
STN EQP CHGS 


2.6.4 Detailed Table / Column Mapping 

N/A 

2.6.5 Data Dependencies 

Prior to creating equipment types the (RRA__CHG__TYPS) table must be 
populated with all relevant charge types. 

2.6.6 Manual Conversion 

Since only one equipment row has been identified in the analysis of the 
ECARS.ADDLJPRODJTYP table, this will be converted manually for iteration2. 

2.6.7 Assumptions 

Manual conversion due to a low volume of equipment items. 

2.6.8 Issues 

N/A 

2.6.9 Data Volumetrics 

1 

2.6.10 Data Validation Criteria 

Data validation will happen through SQL scripts, RatesEngine test harness and 
investigating the NotConverted and log files. 
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2. 7 Functional Area : Ancillary Charges 

Due to the Age Limit requirements, it has been decided that UNDERAGE (Young 
Renter Fee) records will not be converted. Section will remain for reference 
purposes only, this mapping can be used if required in future iterations. (Ignore 
anything referenced as 'UNDERAGE') 

2.7.1 Data Transformation Rules 

In ECARS, currently we have 'ADDLDRVR' and 'UNDERAGE' as additional 
products. There are more additional products defined in the system, but based on 
the data investigation, only these two need to be converted with relation to 
'R'etail Default Products in iteration 2. 


Complete List of Additional products in ADDL PROD TYP table and counts 
from PLN_ADDTL_PROD_RATE table is provided below. 


Product 

Description 

Number of rows in 
PLNADDTLJPROD RATE 
table 

ADDLDRVR 

Additional Driver 

166 

UNDERAGE 

Underage Driver 

42 

BABYSEAT 

Baby Seat 

0 

SKI RACK 

Ski Rack 

1 

OVER 70 

Driver over 70 years old 

0 

UNKNOWN 


3 

FUTURE ('D' - Deleted status) 


0 

CHARGE ('D' - Deleted status) 

Additional charge 

0 


There are two tables in SI that stores additional product information. 

1 . ADDL PROD TYP - a reference table which defines the additional product 

2. PLN_ADDTLJ>ROD JtATE - stores additional product rates information 
related to the rate plans. 


The PLN_ADDTL_PROD_RATE table has a relationship with the RATEJPLAN 
table through which additional products can be associated with rate plans 
(Attributes GRPJD and RATE J>LAN_SEQ_NBR) 

UNDERAGE records from PLN_ADDTL J>ROD JRATE table will be written to 
MINAGE JRSTRS table in VRS 

2.7,2 Data Selection Criteria 

Additional products are associated with Rate Plans. For conversion purpose, Rate 
Plans that have defaults will be retrieved along with additional products for that 
rate plan. If there are additional products for that rate plan, then all the default 
hierarchies associated with the rate plan will be retrieved and converted as 
ADDLDRVR / UNDERAGE product at that hierarchy. 

Retrieval / Conversion Logic: 
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- Retrieve all active rate plans from DFLT_RATE_PLAN (which will read all 
the retail rate plans that have defaults), which have Additional products using 
a JOIN between DFLT_RATE_PLAN and PLN_ADDTL_PROD RATE 
tables. 

Select criteria is as follows: 

• The rows with a BusinessType of 'Retail will be retrieved. 

• The rows with a RecordStatusCode equal to <null>or Tnactive will 
be retrieved., 

- Convert each hierarchy to an appropriate VRS User Defined Area (UDA) 
using CONV_PROD_XREF table which is populated during Rates 
conversion. (A common function can be written to use across all the 
conversion modules). 

- Perform validations on the retrieved data. 

- Prepare the data into a VRS data structure and write to VRS tables. 

- Write the exception errors and conversion history to log files for later 
inspection. 

Data from PLN_ADDTL_PROD_RATE will be written to two tables based on 
the Additional Product Type. 

1 . If the Additional Product Type is UNDERAGE, then it will be written to 
MIN_AGE_RSTRS table. 

2. If the Addl. Product Type is ADDLDRVR, then it will be written to 
ADDLDVRFEES table. 


2.7.3 Source and Target Table Impacts 


Source Tables 

Target Tables 

BR DFLT 


AREA XCHNG DFLT 


ZIP CODE DFLT 


AREA DFLT 


ST DFLT 


REGN DFLT 


GRP DFLT 


DFLT 


DFLT RATE PLAN 


ADDL PROD TYP 


PLN ADDTL PROD RATE 



MIN AGE RSTRS 


ADDL DVR FEES 
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2.7.4 Detailed Table / Column Mapping 


Underage Conversion (Not beins converted) 


ECARS TABLEFieldName 

Population Rule 

VRS TABLEMeldName 

Xxxx pn.T£usmessTypeCode 


WWjKGE^TRS.ProductTypeCode 

XxxxJftVT.GroupId 
XxmJ)FLTJBranchId 

Based upon the Groupid and Branchld, the 
conversion module will produce an 
appropriate UserDefmedAreald (possibly 
cross-referencing to the PeopleSoft codes) 
and tie it to an AreaType of ATY_xxxx 

MMJJGEJIStRS.UserDefinedAreald 
MINAGE_RSTRS. VserDefimdAreaType 

?LN_j&D7LJRODJUWE.RatePlariSeqNbr 

This value is retained for retrieval of 

Additional products from 

PLN ADDTL PROD RATE table 

No conversion required 

?LNJ&DTL_PRODJLkTEAddlProdCde 

This value is retained to determine which 
table the infoamtion need to be written 

No conversion required 

PLN ADDTL PROD RATE.RateTypeCode 
VlNJ&Un.JROVJUWEAddlChrgAmt 

Based on the value of the RateTypeCode, 
populate one of the following VRS 
attributes from 

PLN_ADDTL_PROD_RATE.^^CAr^ 
mt 

MIN AGE RSTRS. YngRntrFee 
MIN AGE RSlR$.Renta!MaxFee 



IfRateTyp-'DAY' 

Populate MINAGE_RSTRS. YngRntrFee 
From 

PLN ADDTL ?RGDRATEAddlChrgAmt 


IfRateTyp='RNr 

Populate MIN JKGEJRST&S. YngRntrFee and 

Mmj±GEJRSTRS.RentalMaxFee 

From 

PLN _ADDTL ?RODJUaEAddlChrgAmt 

PLN ADDTL PROD RATE.CntrctOffilnd 
\ PLN_ADDTL_PRODJRATEJ«c/c/£KrteW 
\ PLN ADDTL ?ROD_RATEJnstructRqmtJnd 

Not Converted 


PLN ADDTL PROD RATEMaxAmt 

Not converted 


PLN ADDTL PROD RATE.MaxDayNbr 

PLN ADDTL PROD RATEStrtKeyDte 
; i PLN ADDTL PROD RATEStrtKeyTim 

The date and time will be concatenated 
and stored in Start Date column in VRS 

MN^AGEJ&STRSStrtDt 

i PLN ADDTL PROD RATEEndDte 
\[ PLN ADDTL PROD RATEEndTim 

The date and time will be concatenated 
and stored in End Date column in VRS 

MIN_AGE_RSTRS . EndDt 

/ PLN_ADDTL_PROD_RATE. RecStatlnd 
\\ RecAddDte 
j, RecAddTim 

RecAddEmpMbr 

RecAdPgmJobNam 

RecChngDte 
' RecChngeTim 

RecChngEmpNbr 

RecChgPgmJbNam 


Not required for conversion. 

New Audit values will be populated into Audit 

related columns. 





In certain situations, ERAC table information is not sufficient to populate VRS 
tables completely and some information would have to be filled based on the 
design guidelines. 


VRS Table 

VRS Column 

Data Type 

VRS Population Rule 


MIN AGE RSTRS 

PRT PROD TYP CDE 

Varchar2(2) 

Setto'R' -Retail 



UDA AREAJD 

Varchar2(20) 

Based upon the Groupid and Branchld, the 
conversion module will produce an 
appropriate UserDefmedAreald (possibly 
cross-referencing to the PeopleSoft codes) 
and tie it to an AreaType of ATY_xxxx 



UDA_ATY_ARRA_TYP 

Varchar2(10) 



VCA CAT CD 

Varchar2(S) 

Setto'ACAR' 



VCA CLASS SUFX 

Varchar2(4) 

Set to 4 *** 



FEE TYPE CD 

Varchar2(l) 

Set to 4 S' - Standard for Default Products 



REQ_AGE 

Number(3) 

Populate a default value = 16 

Not available 


Last Save Date: 1 1/1/2001 10:25 AM 


Page 49 of 83 


Data_ConversionJ3esign__I3 


rent-a-car 


;i - 


Data Conversion Detail Design 
ECARS v2.0 - Accurate Out the Door Pricing 


perotsystems 



MAX AGE 

Number(3) 

Populate a default value « 24 

Not available 


STRTJDT 

Date 

Value from 

?lMJ&DTLJ>RODJATEStrtKeyDte 
and StrtKeyTim 



END_DT 

Date 

Value from 

PLN_ADDTL__PROD_RATE.S/r^Dte 
and StrtKeyTim 



YNG_RNTR_FEE 

Number(15,3) 

Value from 

PLN ADDTL PROD RATEAddlChgrgAmt 
iftheRateTypCde- 'DAY' 



RENTALMAX.FEE 

Number(15,3) 

Value from 

PLN ADDTL PROD KKTEAMChgrgAmt 
if the RateTypCde = 'WT' 



CRY_ARIMP__CRY_CD 

Varchar2(2) 

NULL - not required 



MEN DVG LIC PRD 

Number(3 s 0) 

NULL - not required 



BTY TYP 

Varchar2(2) 

NULL -not required 








AddlDriver Conversion 

ADDLDRVR records from PLN_ADDTL_PROD_RATE table will be written to 
ADDL DVR FEES table in VRS 


ECARS TABLE, FieldName 

Population Rule 

VRS TABLKFieldName 

Xxxx DFLT. BusinessTypeCode 


ADDL DVR WESfroductTypeCode 

XxxK_DFLT.GroupId 
'XxxxjyFLT.Branchld 

Based upon the Groupld and Branchld, the 
conversion module will produce an appropriate 
UserDefmedAreald (possibly cross-referencing to 
the PeopleSoft codes) and tie it to an AreaType of 
ATY xxxx 

ADDLJDVRJFEES . UserDefinedAreaJd 
ADDLDVRJEES.UserDefimdAreaType 

PLN ADDTL PROD RATE.RatePhnSeqN 
br 

This value is retained for retrieval of Additional 
products from PLN ADDTL PRODJtATE table 

No conversion required 

?LNJ&mhJ>RODJiATEAddlProdCde 

This value is retained to determine which table the 
infoamtion need to be written 

No conversion required 

?WJ^DTLJRODJATE.RateTypeCode 

Based on the value of the RateTypeCode, one of the 
following columns will be populated. 



IfRateTyp-'DAY' 

ADDL DVR ¥EES.FeeUnitCd - 'D' 


IfRateTyp = 'RNT 

ADDL DVR FEESFeeUnitCd = 7?' 

PLN ADDTL PROD RATEAddlChrgAmt 


ADDL DVR FEESIeoHbr 

, PLN ADDTL PROD RATE.CntrctOffrlnd 
PLN ADDTL PROD RATEJncldEnrtelnd 
PLN ADDTL PROD RATEJnstructRqmtln 
d 

Not converted 


PLN ADDTL PROD RAlEMaxAmt 
PLN ADDTL mOD_RAlEMaxDayNbr 

Not converted 


PLN ADDTL PROD RATEStrtKeyDte 
PLN ADDTL PROD RATEStrtKeyTim 

The date and time will be concatenated and stored 
in Start Date column in VRS 

ADDLJDVR_FEES.SfirtD* 

PLN ADDTL PROD RATE.EndDte 
PLN ADDTL PROD RMEAndTim 

The date and time will be concatenated and stored 
in End Date column in VRS 

ADDLJDVR_FEES.£?wJD/ 

PLN_ADDTL_PROD_RATE. RecStatlnd 

RecAddDte 

RecAddTim 

RecAddEmpNbr 

RecAdPgmJobNam 

RecChngDte 

RecChngeTim 

RecChngEmpNbr 

RecChgPgmJbNam 


Not required for conversion. 

New Audit values will be populated into Audit 

related columns. 





In certain situations, ERAC table information is not sufficient to populate VRS tables 
completely and some information would have to be filled based on the design guidelines. 


VRS Table 


Column Name 


DataType 


VRS Population Rule 


Remarks 
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ADDL DVR FEES 

PRT PROD TYP CDE 

Varchar2(2) 

Set to 4 R f - Retail 



UDA AREA ID 

Varchar2(20) 

Based upon the Groupld and Branchld, the 
conversion module will produce an 
appropriate UserDefinedAreald (possibly 
cross-referencing to the PeopIeSqft codes) 
and tie it to an AreaType of ATYjcxxx 



UDA_ATY_ARRA_TYP 

Varchar2(10) 



FEE TYPE CD 

Varchar2(I) 

Set to 4 S' - Standard for Default Products 



BEGIN QTY NBR 

Number(I2) 

Set to 1 

Not available 


END_QTY_NBR 

Number(12) 

NULL 

Not available 


STRT_DT 

Date 

Value from 

ViM_ADT>TL^RODJiATE.StrtKeyDte 
and StrtKeyTim 



END_DT 

Date 

Value from 

pln^addtl^prod^ratr^a:^/)^ 

and StrtKeyTim 



FEE_NBR 

Number(15,3) 

Value from 

PLN ADDTL ?RODJRATBAddlChgrgAmt 



RENTAL_MAX_FEE 

Number(15,3) 

Value from 

PLN ADDTL PROD RATE A ddlChgrgAmt 



FEE UNIT CD 

Varchar2(l) 

Defaults to "D" 



2.7.5 Data Dependencies 

j;J USR_DFND_AREAS and CONV_PRODXREF tables have been pre-populated 

|JJ 2.7,6 Program Modules 

rip A single program module will be created to convert All Additional products from 

O the source table. Arguments can be used to populate a particular type of products. 

H The absence of arguments will convert all products. 

! si 

J The main module for converting Additional Products will be 

CNVA00001 _ This will consists of sub-functions and external calls to common 
Ijt routines (Retrieve, validate, process and write data to the database) 

hi 

% 2.7.7 Manual Conversion 

N/A 

2.7.8 Assumptions 

Additional Driver Assumptions 

1 . The Additional Products in VRS will be associated with 'Product Type' (ex. 
Line of Business - 4 R' - Retail, T - Insurance etc.) only. 

2. Based on the defaults associated with the rate plan in SI, VRS will populate a 
corresponding User Defined Area (UDA) and associate the additional 
products with the UDAs. 

3 . If any locationis populated with a rate type - RNT' and that location does 
not have another record with a rate type 'DAY', the record will be populated 
with a daily amount and Rental max fee equal to the Per rental amount from 
SL 

4. If rate type = "RNT" and the MaxAmt column on the same record is greater 
than 0, only the AddlChrgAmt amount will be used. 
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5. If rate type = "DAY" and the MaxAmt on the same record is greater than 0 
then charge amount will be mapped to FeeNbr column and the MaxAmt will 
be mapped to the RentalMaxFee column 

Underage Assumptions (not being converted) 

1 . REQ_AGE and MAX__AGE values are not available from SI. For conversion 
purpose, the following values will be populated for the records that have fees 
associated. REQ_AGE - 16 and MAX_AGE - 24 

2. Audit Columns will be populated with the Conversion date, time and 
conversion specific Ids' 

3. The Additional Products in VRS will be associated with 'Product Type' only 
(ex. Line of Business - 'R' - Retail, T - Insurance etc.). 

4. Based on the defaults associated with the rate plan in SI, VRS will populate a 
corresponding User Defined Area (UDA) and associate the additional 
products with the UDAs. 

5. VRS supports the Young Renter Fee (UNDERAGE) at the Car Class level and 
these are mandatory columns. Since SI do not have any car class information 
in the PLN_ADDTL_PROD_RATE table, for conversion, 'ACAR' (All Car 
Classes) will be populated. 

6. If any hierarchy is populated with a rate type ='RNT' and that hierarchy do 
not another record with a rate type C DAY\ the record will be populated with 
a daily amount and Rental max fee equal to the Per rental amount from SI. 

6. If rate type = "RNT" and the MaxAmt column on the same record is greater 
than 0, only the AddlChrgAmt amount will be used. 

7, If rate type = "DAY" and the MaxAmt on the same record is greater than 0 
then charge amount will be mapped to FeeNbr column and the MaxAmt will 
be mapped to the RentalMaxFee column 


2.7.9 Issues 

N/A 


Last Save Date:l 1/1/2001 10:25 AM 


Page 52 of 83 


Data_Conversion_Design_I3 


Enterprise 


renT-a-«ar 


Data Conversion Detail Design 
ECARS v2.0 - Accurate Out the Door Pricing 


perotsystems" 


2.7.10 Data Volumetrics 

According to the data received from ERAC during 2 nd week of June, from 
Central, Midwest and North Systems. 


PLNADDTLPRODRATE 


Category 

Total 

'A'ctive 

'D'elete 

Tnactive 

# of rows 

212 

148 

60 

4 

Rows associated with DFLT RATE PLAN 

85 

49 

32 

4 

Rows associated with 'A'ctive 'R'etail Rate 
Plans 

17 

5 

12 



2.7.11 Data Validation Criteria 

Data validation will happen through SQL scripts, RatesEngine test harness and 
CI investigating the NotConverted and log files. 


III 

u. I. 


5'% 5 
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I 

CI 


2, £ Functional Area: Insurance/Coverages 


2.8.1 Data Transformation Rules 

Coverages are associated with either Rate Plans (Default) or Agree Bill Types 
(Agreements) in ECARS model. Since the Iteration-2 only deals with Retail rates 
(Default), the Coverages related to the Default 'R'etail Rate Plans will be 
converted in iteration 2. 

Default Coverage information is stored in two tables: 

1 . COVJT YP - a reference table to define Coverage Types and 

2. PLANCOVJRATE - stores coverage information related to the Default Rate 
Plans. There is a relationship with RATEJPLAN table to associate coverages 
to the default rate plans. When a rate plan is selected, associated coverages are 
retrieved using the relationship between the two tables. 

List of Coverage records in SI: 


Coverage Type 

Description 

DW 

Damage Waiver 

PAI 

Personal Accident Insurance 

SLP 

Supplemental Liability Protection 


!|| COVJYP record will be written to INS_TYPS table and PLAN_COV_RATE 

m records will be written to INS PRVS table. 


-.sr. 
I i 

1#F 


H - 2.8.2 Data Selection Criteria 

Coverages are associated with Rate Plans. For conversion purpose, Rate Plans 
that have defaults will be retrieved along with coverages for that rate plan. If there 
are Coverages for that rate plan, then all the default hierarchies associated with 
the rate plan will be retrieved and the corresponding coverage records will be 
converted to INS_PRVS table in VRS. 

Retrieval / Conversion Logic: 

- Retrieve all active rate plans from DFLT^RATE^PLAN (which will read all 
the retail rate plans that have defaults), which have Additional products using 
a JOIN between DFLT JRATE J>LAN and PLAN_COV_RATE tables. 

Select criteria is as follows: 

• The rows with a BusinessType of 'R'etail will be retrieved. 

• The rows with a RecordStatusCode equal to <null> or Tnactive will 
be retrieved 
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- Convert each hierarchy to an appropriate VRS User Defined Area (UDA) 
using CONV J>ROD_XREF table, which is populated during Rates 
conversion. (A common function can be written to use across all the 
conversion modules). 

- Perform validations on the retrieved data. 

- Prepare the data into a VRS data structure and write to VRS tables. 

- Write the exception errors and conversion history to log files for later 
inspection. 

- If multiple rate plans are encountered at a location, then the Rate Plan details 
will be logged in to an exception file and the coverage records will not be 
converted. 
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Two new attributes - COV_LMT_AMT and FULL_COV_FLG attributes have been 
added to INS_PRVS table to support ERAC existing data. These attributes will be 
populated from COV_LMT_AMT and FULL_COV_IND attributes of 
PLAN COV RATE table. 


ECARS TABLE, FieldName 

Population Rule 

VRS TABLE FieldName 

XxxxJDFLT.BusinessTypeCode 


INS PRVS.ProductTypeCode 

XxxxJbPLT.GroupId 
XxxfpWC.Branchld 

Based upon the Groupld and Branchld, the 
conversion module will produce an appropriate 
UserDefinedAreald (possibly cross-referencing to 
the PeopleSoft codes) and tie it to an AreaType of 
ATY xxxx 

WSJRVS.UserDefmedAreald 
WSJPRVS.UserDejjnedAreaType 

PLAN_COV_RATE.C<7v2>pOfe 

Based on the Coverage Type code, retrieve 
COVJNITLjrYP_CD£ from COV_TYP table and 
populate as INTJNS TYP ID in VRS table 

TNS_PRVSJntImTypId 

PLAN COV RATE.CarCIassId 


INS PRSlS.VehicleCategoryCode 

PLWJCOVJUtfErarClassSuffixId 


INS PRVS.CarClassSuffixId 

?LANJZOV _pATE JlateTypeCode 
Phm JZOVJRKYE.CoverageRateAmt 

Based on the value of the RateTypeCode, one of the 
following columns will be populated. 



DAY 

INS ?RV$.DailyPrm 


WK 

INS PRVS.WeeklyPrm 


MTH 

INS ?RVSMonthlyPrm 


RNT - Not converted 

VRS do not support this. Based on the data 
investigation, 'R'etail conversion doen't have 
any impact. But needs resolution moving 
forward with other iterations. 

PLANT COV RKXE.CovDeductibleAmt 


INS PRVSEXCS DPST 


The amount will be extracted and stored in 
Coverage Limit Amount in VRS. 



The indicator mil be extrcated and stored in Full 





PLAN COV RAlE.CntrctOffilnd 
PLAN COY~RATEJncludeInRate 
PLAN COV RkTE.Requiredlnd 

Based on the value of the these columns, one of the 
following values will be populated. 



If PLAN COV RKi%.CmrctQffrlnd='r 

INS PRVS ApplStat = 'D' - Do not offer 


If PLAN COV RATEJncludelnRate^'r 

INS^PRVS.^pp/S'to? = T -Included in the rate 


lfPLAH_COV JfATRRequiredlnd^ T 

INS_ PRVS ApplStat = 'M' -Mandatory 


If all of the above attributes are set to *N S 

INS PRVS ApplStat = V -Optional 

PLAN COV RATEMaxAmt 

Conversion not required. 


PLAN COV RKTEMaxDayNbr 

Conversion not required. 


PLAN COV RATEStrtKeyDte 
PLAN COV RAlEStrtKeyTim 

l ne date ana tune wm oe conuxicnaicu ana siurcu m 

OldTC U3VC COIUTTUl 1U V ISO 

NSJ>RVS.StrtDt 

PLAN COV RATEEndDte 
PLAN COV RATEEndTim 

The date and time will be concatenated and stored in 
End Date column in VRS 

TNSJPRVSEndDt 

PLAN COV RAJE.RecStatCde 


Conversion not required 

VLANJZOV JRATE AddDte 

AddTim 

AddEmpNbr 

AddPgmJobNam 

ChngDte 

ChngTim 

ChngEmpNbr 

ChngPgmJobNam 

Conversion not required. 

No audit columns available in INS^PRVS table. 


INSJTYPS, which is a coverage reference table in 
VRS need to be populated before Coverages 
conversion 


COV TYP. CovInitlTypCde 


INS TYPSJnsTypId 

I COV TYP.CovTypDsc 


INS TYPSJnsTypDesc 


Last Save Date:l 1/1/2001 10:25 AM 


Page 56 of 83 


Data_Conversion_DesignJ3 


Enterprise 


Data Conversion Detail Design 
ECARS v2.0 - Accurate Out the Door Pricing 


perotsystems™ 


2.8.3 Source and Target Table Impacts 


Source Table 

Target Table 

COV TYP 

INS TYPS 

PLAN COV RATE 

INS PRVS 


2.8.4 Detailed Table / Column Mapping 

Fields retained from ECARS Database 


VRS Table 

VRS Column 

Data Type 

VRS Population Rule 

INS PRVS 

♦PRM ID 

NUMBER(7) 

Unique Sequence number will be generated 


•INTJNS_TYPJD 

VARCHAR2(8) 

Value from 

PLAN COV RATE CovTwCde and 
translated to 

COV TYP.COF 7M7X 77P C£>£ 


•STRTJDT 

DATE 

Value from PLAN COV RATE^/rt&^te 
and PLAN COV RATEStrtKeyTim 


APPLSTAT 

VARCHAR2(1) 

Value from one of the PLAN_COV_RATE 
attributes 

l D ' - Do not offer ifCntrctOffeerlnd - T 1 

T-ifNcldEnrtelnd^Y' 

'M'-ifReqlnd** T 

V'-if all theree are set to W ' 


CCO_CNTRCTL CND ID 

NUMBER(8) 

NULL - for Product related coverages 


CRY ARMP CRY CD 

VARCHAR2(2) 

Set to 'US' 


ENDJDT 

DATE 

Value from PLAN_COV_RATE.£^Dfe 

and PT A"KF PHV PA TP £W/77m» 


EXCSJDPST 

NUMBER(15,3) 

Value from 

PLAN COV RAYE.CovDdctblAmt 


PRI PROD INST CD 

VARCHAR2(8) 

NULL 


PRI._VER.NBR 

NUMBER(3) 

NULL 




IN u LL — not used 


RES STRT DT 

DATE 

NULL - not used 


T in A ARFA TPk 

V A T> CU A T? 0 fQ\ 

VAKUrlAK2(o) 

Derived uuA ana UDA Type from the 
Default 


UDA ATY AREA TYP 

VARCHAR2(10) 


vca cat rn 

VAPPl4AP0/^\ 

value trom r LAN CUV KA1 b.CarC /sia 


CAR_CLS_SUFX_ID 

VARCHAR2(4) 

Value from 

PLAN_.COV RATE.CarClsSufxId 


INS UNBLD DLY AMT 

NUMBER(15,3) 

NULL - not used 


IP_PROD CAT CD 

VARCHAR2(1) 

NULL - not used 


PRT_PROD_TYP_CD 

VARCHAR2(2) 

Set to 'R 1 (Refers to 'R'etail in 
PROD TYPS table) 


DLY_PREM 

NUMBER(15,3) 

Value from 

PLAN COV RATEJtoteTypCde and 
PLAN COV RATE.CovRateAMt 
If RateTypCde - 'DAY', then CovRateAmt 
is populated in this column 


WKLYJPREM 

NUMBER(15,3) 

Value from 

PLAN COV RATE.RateTypCde and 

?LANSOVJLATE.CovRateAMt 

If RateTypCde = 4 WK\ then CovRateAmt is 

populated in this column 


MTHLY_PREM 

NUMBER(15 ? 3) 

Value from 

PLAN COV RATE.itote7tf?ate and 

?LANJ20VJAJE.CovRateAMt 

If RateTypCde = k MTH\ then CovRateAmt 

is populated in this column 
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VRS Population Rules 

In certain situations, ERAC table information is not sufficient to populate VRS tables 
completely and some information would have to be filled based on the design 
guidelines. 


VRS Table 

VRS Column 

Data Type 

VRS Population Rule \ 

UNb 1 YPS> 

•CRY ARJMP CRY CD 

Varchar2(2) 

Use 4 US' country code 


•INS TYP ID 

Varchar2(8) 

Value from COV TYP JmtlTypCde 


•rw9 typ np^p 

varcnar2(/5) 

Value from COV TYP.CovTypDsc 


•RCTjCHGJTYP 

Varchar2(5) 

Derived from RRA CHG TYPS table 
DW - 00006 
PAI - 00007 
SLP -00032 


CREATE USER ID 

Varchar2(30) 

Set to 'CONV-COVERAGE' 


CREATE DT 

Date 

Conversion Date and Time 


LAST UPDT USER ID 

Varchar2(30) 

NULL 


LAST UPDT DT 

Date 

NULL 


•INS CND LN1 

Varchar2(75) 

Value from COV TYP.CovTypDsc 


ASSOC 

Varchar2(l) 

NULL - Not used for ECARS 


INS CND LN2 

Varchar2(75) 

NULL - Not used for ECARS 


•INS SUPER TYP CD 

Varchar2{3) 

Value from COV TYPJnitlTypCde 


INS_SUPER TYP ORD NBR 

Number(2) 

NULL - Not used for ECARS 


PKG ID 

Number(6) 

NULL - Not used for ECARS 


EC INS ATTACH FLG 

Varchar2(10) 

NULL - Not used for ECARS 






2.8.5 Data Dependencies 

|l - INSTYPS table has been pre-populated. 

- PRODJTYPS table has been pre-populated 


2.8.6 Manual Conversion 

Since there are only few rows in COVTYP table, a SQL script will be used to 
populate rows in INSJTYPS table. 
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INS_TYPS will be created as shown: 


JNSJTYPJD 
DW 

INSJTYPJDESC 
Damage Waiver 

CRY ARIMP CR 
Y CD 
US 

INS_SUPER_TYP_CD 

INSjCNDJLNl 

CREATEJJSERJD 

CREATEJDT 

PAI 

Personal Accident 
Insurance 

US 

DW 
PAI 

Damage Waiver 
Personal Accident 
Insurance 

CONVERSION 
CONVERSION 

System Date 

SLP 

Supplemental 

Liability 

Protection 

US 

SLP 

Supplemental 
Liability Protection 

CONVERSION 



Assumptions 

1 . If a rate plan doesn't have defaults defined, the coverages associated with that 
rate plan will not be converted. 

2. Coverages within the VRS model are going to be maintained at the 
hierarchical levels. 

3. If multiple rate plans are encountered at a location, they will be converted as 
coverages associated with multiple product instances determined by Rates 
Conversion process 

4. If the rate plans are being shared among the hierarchies, related coverages will 
not support this feature anymore after conversion. 

5. Any records that have Rate Type set to 'RNT will not be converted and 
written to an exception file. 

6. The three indicators - TLAN_COV_RATE.C/?rrc/<9^/^ , J 
?LAN_COV_RATE JncludelnRate 9 and VLAN JCOVJ^ATE.Requiredlnd' 
are mutually exclusive. If any records are encountered that have more than 
one indicator set to 'y\ they will be written to exception file and will not be 
converted. 

7. If multiple rate plans are encountered at a location, then the Rate Plan details 
will be logged in to an exception file and the coverage records will not be 
converted. 


2.8.8 Issues 

2.8.9 Data Volumetrics 

PLAN_COVJtATE 


Category 

Total 

'A'ctive 

'D'elete 

# of rows 

2084 

1616 

468 

Rows associated with 
DFLT RATE PLAN 

514 

235 

279 

Rows associated with 'A'ctive 
'R'etail Default Rate Plans 

68 

51 

17 


h 

"Pi? 

m 


ft 


m 


2.8.7 


15 - 

tit 

pi 
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2.8.10 Data Validation Criteria 

Data validation will happen through SQL scripts, RatesEngine test harness and 
investigating the NotConverted and log files. 
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2. 9 Functional Area: General Conditions 


2.9.1 Data Transformation Rules 

One general condition, or message, will be created for each Business Type Code 
and Default Number combination that exists in the default table. For this 
iteration, the retail (R) message type will be the primary focus. 

General Conditions are associated with default messages used for display 
purposes in ECARS model The ECARS conversion retrieval will be made of a 
number of logical retrieval processes. This logical approach will enable us to 
schedule certain levels of conversion/retrieval from ECARS and population of the 
VRS tables, in order to have a faster and more customizable environment. 

The General Condition conversion program will cross-reference information from 
the Conversion Temp table which is populated by the Rate Conversion program, 
tying the Product Instance and UDA to the Rate Plan. 

2.9.2 Data Selection Criteria 

Default General Conditions information is stored in four tables - 1 . DFLT - stores 
the default message number by business type and has some default message 
descriptions for vehicle and fuel for the Default Rate Plan, 2. 
DFLT_MISCJVERB - stores additional message information with a valid date 
range, 3. DFLT_RULE - stores messages and values for rules with a valid date 
range, 4. RULE - stores rule information related to specified rule code. The 
DFLT table has a relationship associated with the DFLTJVIISC_VERB and 
DFLT_RULE table. Associated messages are retrieved using the relationship of 
the default number and business type code from the DFLT table. The RULE table 
has a relationship associated with the DFLTJRULE table. The associated 
messages are retrieved using the relationship of rule code from the RULE table. 

2.9.3 Source and Target Table Impacts 


Source Tables 


Target Tables 


DFLT 

DFLTJVIISCJVERB 

DFLTJRULE 

RULE 


RNT_CNDS 
GEN CNDS 
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2.9.4 Detailed Table / Column Mapping 


Ecars Retrieval 

DFLT 

The entry table will be the DFLT table. This allows us to retrieve all the default 
message numbers and other appropriate information from the ECARS tables. 
The selection criteria is as follow: 

- The rows marked with a BusinessType of 'Retail will be retrieved. 

- The rows with a RecordStatusCode equal to <null> or Tractive will be 
retrieved 


The fields StartDate and EndDate will be retained for examination/usage at a later 
stage. The fields BusinessType and DefaultNumber will be retained and used to 
retrieve the corresponding data from the DFLT JttJLE, and DFLTMISC_VERB 
tables. The UDA derived from the Conversion Temp table will need to retained 
for usage at a later stage 

DFLTJdlSCJfERB 

Using the BusinessType and DefaultNumber all appropriate rows will be retrieved 
from the DFLTMISC^VERB table. 
Further selection criteria are also applied: 

- The rows marked with a BusinessType of 'Retail will be retrieved. 

- The rows with a RecordStatusCode equal to <null> or Tnactive will be 
retrieved 


The fields BusinessType and DefaultNumber will be retained and used to retrieve 
other corresponding data. 

DFLTJtULE 

Using the BusinessType and DefaultNumber all appropriate rows will be retrieved 

from the DFLT_RULE table. 

Further selection criteria are also applied: 

- The rows marked with a BusinessType of 'Retail will be retrieved. 

- The rows with a RecordStatusCode equal to <null> or Tnactive will be 
retrieved 


The field RuleCode will be retained and used to retrieve the corresponding data 
from the RULE table. The fields Valueld, StartKeyDate, StartKeyTime, EndDate 
and EndTime will be retained for examination/usage at a later stage. The fields 
BusinessType and DefaultNumber will be retained and used to retrieve other 
corresponding data. 


RULE 

- Select all appropriate rows from the RULE table. 
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The rows with a RecordStatusCode equal to <null> or Tnactive will be 
retrieved 


The RuleCde will be retained along with the unique id created when the 
general conditions tables is populate. This combination will be used to map 
the correct info message and value id from the default rule table. 

Fields Retained for VRS Population 


ECARS TABLE. FieldName 

Population Rule 

VRS TABLE. FieldName 




xxxxJd'Fm.GroupId 

Based upon the Groupld and Branchld, the conversion 
module will produce an appropriate 
UserDefinedAreald (possibly cross-referencing to the 
PeopleSoft codes) and tie it to an AreaType of 
ATY xxxx 

RNTCNDS. UserDefinedAreald 
RNT_CNDS. UserDefmedAreaType 

DFUY.StrtDte 

The start date will be the lesser of the start dates from 
the DFLT or DFLT RULE table 

KttT_CNDS.StartDate 

DFLLEndDte 

The end date will be the ereater of the end date*; from 
the DFLT or DFLT RULE table 

RNT CNDS FnfTnatP 

DFL1XOC DSC 

Not converted 


DFLT.DFLT CAR PREF DSC 

Not converted 


DFLT DFLT FUEL ONE DSC 

Not converted 


DFll.DFLT FUEL TWO DSC 

Not converted 


DFLT. 

BUS TYP CDE 
DFLTJfBR 
RECJSTATjCDE 
Or L 1 _MJo L _ Vt>Kn 

REC STAT CDE 
DFLT RULE 

BUS TYP CDE 
RULE CDE 
DFLT NBR 
REC STAT CDE 

RULE 

REC STAT CDE 

These values are retained for retrieval of additional 
messages or rules 

No conversion required 

DFLT. 

ADDJDTE 
ADD TIM 
ADDJSMP_NBR 

ADD PCi\A IDlk NAM 
CHNG DTE 
CHNG TIM 
CHNG EMP NBR 
CHNG PGM JOB NAM 

Not converted 



same as RNT CNDS.GCD CND ID 

GEN CNDSCND ID 

DFLT MISC NEKB.VERB TXT 


GEN CNDS.CND LNI 

DFLT RULE.INFOMSG TXT 


RNT CNDS.CMT LNI 

DFLT MISC VERB 

VERB TYP ID 
VERB NBR 
ADD DTE 
ADD TIM 
ADD EMP NBR 
ADD PGM JOB NAM 
CHNG DTE 
CHNG TIM 
CHNG EMP NBR 
CHNG PGM JOB NAM 

Not converted 


DFLT RULE 

ADD DTE 

Not converted 
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ADD_iIM 
jdnn t?mt> kivii> 

ADD PGM FOR NAM 
CHNG DTE 
CHNG TIM 



DFLT RULE. VAL ID 


RNT CNDS.CV/r LN2 ~J 

RVLE.FLD DSC 


GEN CNDS.LN1 

RULE.INFO MSG TXT 


GEN CNDS.LN2 

RULE. RULE CDE 

Must be retained with the GEN CNDS.CND ID 


RULE 

FLD NAM 
MIN MAX IND 
RULE OWNER ID 
ROUT ID 
VAL CDE 

ADDJDTE 

Ann ti\a 
ADD 11M 

ADD EMP NBR 

ADD PGM JOB NAM 

CHNG DTE 

CHNG TIM 

CHNG EMP NBR 

CHNG PGM JOB NAM 

Not converted 



VRS Population Rules 


In certain situations, ERAC table information is not sufficient to populate VRS 
tables completely and some information would have to be filled based on the 
design guidelines. 

For every BusinessTypeCode and DefaultNumber combination in the DFLT 
table joined with the DFLTJVUS C_VERB table, there will be a row created in 
the VRS GENCNDS and will be attached to RNT CNDS table. For multiple 
rows retrieved with the same DefaultNumber, the VERBJTXT will be added to 
the next available line in the GEN_CNDS table CNDJLK The RULE table and 
the DFLT_RULE table will be converted as described below. 

The Product Code in RNT_CNDS table will be populated from the reference 
table of Rate plan/Product Code generated by the rates conversion process. 

The basic rules for conversion of the RULE codes are: 

- The general conditions table must be populated first from the rules table 
before the information from the DFLTJRULE table can be retrieved. 

- An entry in the general conditions table will be created for every active 
row in the rule table. 

- The unique ID created from the insert above must be retained with the 
appropriate rule code to map the rule code in the default rule table back to 
the correct general condition row referenced when attaching it to the rental 
conditions created. Val _id and info message values from DFLTJRULE 
table will be populated into the RNT_CNDS table. 

- For every row in the DFLTJRULE and hierarchy table combination, a row 
in the RNT CNDS will be created using the rule code and the unique 
general conditions id retained above to link them. 
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A new attribute DIST_CHNL_CDE has been added to the RNT CNDS table and this 
attribute will be populated with a default value of ' Branch ' while converting SI data. 
Appropriate code changes will be made to incorporate this change. 


VRS Table 

VRS Column 

Data Type 

VRS Population Rule 

RNi CNDS 

UserDefimdAreald 

Varchar2(8) 

Based on level Grpld 


UserDefinedAreaType 

Varchar2(10) 

Set to 'ATY xx' 


RCI ID 

Number(8) 

Unique Sequence Number will be generated 


DSP STAT 

Varchar2(8) 

Default to 'D' 


GCD CND ID 

Number(6) 

Value from GEN CNDS.CND ID 


STRTjDT 

Date 

Lesser of values from DFLT.STRT DTE 
And DFLT RULRSTRT KEY TIM || 
DFLT RULE.STRT DTE 


END_DT 

Date 

Greater of values from DFLT.END DTE 
And DFLT_RULE.END_KEY_TIM j| 
DFLT RULE.END DTE or NULL 


CCOjONTRCTL CND ID 

Number(8) 

NULL - Not used for ECARS 


PRI PROD INST CD 

Varchar2(8) 

Determined by the Rate Conversion process 


PRI VER NBR 

Number(3) 

Default to T 


Pi?OZ) ID 

Varchar2(4) 

NULL - Not used for ECARS 


£AT) DT 

Date 

NULL - Not used for ECARS 


RES START DT 

Date 

NULL - Not used for ECARS 


RNTJ0MTJLN1 

Varchar2(75) 

DFLT RULE.INFO MSG TXT from 

DFLTRULE table or DFLT_MISC_VERB_TXT 

from .DFLT MISC VERB table or 

DFLT RULE.VAL ID if 

DFLT RULE.INFO MSG TXT is null 


RNT CMT LN2 

Varchar2(75) 

DFLT RULE.VAL ID 


RNT DESC 

Varchar2(2000) 

NULL - Not used for ECARS 


RNT PROD CAT 

Varchar2(l) 

NULL - Not used for ECARS 


VehicleCategoryCode 

Varchar2(8) 

Default Vehicle Code (ACAR) 


VehicleCategoryCodeSuffix 

Varchar2(4) 

Default Vehicle Suffix (**) 






VRS Table 

VRS Column 

Data Type 

VRS Population Rule 

GEN^CNDS 

CND ID 

NUMBER(6) 

Unique Sequence number will be generated 


TYP 

VARCHAR2(20) 

Default to "Retail" 


CND LN1 

VARCHAR2(75) 

DFLT MISC VERB. VERB TXT 


CND LNI 

VARCHAR2(75) 

RULE.FLD DSC 


CND LN2 

VARCHAR2(75) 

RULE.INFO MSG TXT 


CND LN3-30 

VARCHAR2(75) 



f! 


III. 


in 

ill 


ISP 
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2.9.5 Data Dependencies 
VRSData Model 


V*. p 

W 

m 

. "S - 


hi 
ill 

III 



RNT CNDS 



#RCN_ID 


NUMBER(8) 

#DSP_STAT 


VARCHAR2(1) 

#*GCD_CND_ID 


NUMBER(6) 

#*STRT_DT 


DATE 

* CCOj:NTRCTL_CNDJD 

NUMBER(8) 

END_DT 


DATE 

* PRI_PROD_INST_ 

.CD 

VARCHAR2(8) 

* PRI~ VER_NBR 


NUMBER{3) 

PROD_ID 


VARCHAR2(4) 

RES_END_DT 


DATE 

RES_STRT_DT 


DATE 

RNT_CMT_LN1 


VARCHAR2(75) 

RNT_CMT_LN2 


VARCHAR2(75) 

RNT_DESC 


VARCHAR2(2000) 

* RNT_PROD_CAT 


VARCHAR2(1) 

* UDA_AREA_ID 


VARCHAR2(10) 

* UDA_ATY_AREA 

_TYP 

VARCHAR2(10) 

* VCA_CAT_CD 


VARCHAR2(8) 

* CAR_CLS_SUFX_ 

CDE 

VARCHAR2<4) 

PRTJPROD_TYP_CD 

VARCHAR2(2) 

DIST_CHNL_CDE 


VARCHAR2(12) 


STA UDA 
ATY_AREA_TYP 
AREAJD 
AREA DESC 


PROD INSTS 
PROD_INST_CD 
VER NBR 



GEN CNDS 

#CNDJD NUMBER(6) 
#TYP VARCHAR2(20) 
#CND_LN1 VARCHAR2(7S) 
CND_LN2VARCHAR2(7S) 
CND_LN3-30 VARCHAR2{75) 


2.9.6 Manual Conversion 

N/A 

2.9.7 Assumptions 

1 . Car Class ID and Car Class Suffix ID are going to be of lengths 8 and 4 
respectively. 
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2. Vehicle Category Code (ACAR) and Suffix (**) will be used for all Retail 
messages. 

3. We do not need to map the LOCJDSC field from the DFLT table. 

4. If the field targeted to populate the GEN_CND S . CND_LN 1 is null, then the 
field targeted to populate the GEN_CNDS.CND_LN2 will be used to populate 
CNDJLNL This is true for RNTCNDS comment lines 1 and 2 also. 

5. The data in the DFLTJR.ULE.va/_zc/ will be corrected by Data management 
group before the conversion program runs. 

6. Each message will be converted as is. 

2.9.8 Issues 


2.9.9 Data Volumetrics 

The table below represents some volume metrics from the ECARS database. 
These are based upon a database refresh received by PSC on June 1 1, which 
represents three of the eighteen ECARS machines. Since the Iteration 2 only 
deals with Retail rates (Default), only these General Conditions will be converted. 


Ecars Table 

Num Rows 

Num Rows 
Active 

Num Rows 
Delete 

Num Rows 
Inactive 


DFLT 

161 

53 

79 

29 

DFLT_MISC_VERB 

401 

187 

214 


DFLTRULE 

100 

78 

22 


RULE 

20 





For each logical level retrieved, as explained in the rate conversion section, the 
BusinessType and DefaultNumber obtained will be used to select the appropriate 
rows from the DFLTJVIISCVERB and DFLTJR.ULE tables. The following 
section describes, the retrieval from the ECARS tables based on the BusinessType 
and DefaultNumber, which fields are retained and how and where this information 
will be populated in the VRS tables. 


2.9.10 Data Validation Criteria 

Data validation will happen through SQL scripts, RatesEngine test harness and 
investigating the NotConverted and log files. 
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2.10 Data Bridges - Conversion and On-going Maintenance 

2.10.1 UDA Hierarchy 

2.10.1.4 Characteristic Information 


Is! 


pi 

m 
M 

yl 


|bssj 


1U- 


Enterprise branch data is currently maintained on the OFC_DIR_BR and 
OFC_WW_DIR tables. The VRS application uses the STNS, 
USR_DFND_AREAS and AREATYPS tables to maintain branch and 
corresponding rate hierarchy data For Enterprise VRS implementation, it is 
assumed that the branch data will continue to be maintained in the 
OFC_DIR_BR and OFC_WW_DIR tables. There will be a one-time 
conversion of existing Enterprise branch data to corresponding VRS entities. In 
addition, there will be ongoing data bridging activity to ensure branch and 
station data synchronization. 


VJ XJCt I Jill VUlllCAl* 

szj\j\k^ ubcr maintains ine jorancn miormation in tne hcaKd rSrancft tables. 
This information is mapped to VRS Stations, User Defined Areas and other 
related entities. This happens during the conversion and as a part of on-going 
data maintenance activity. 

Scope: 

This Use Case deals with Insert/Update activity on the Branch tables as a main 
actor. This use case does not cover the scenarios for maintaining the VRS 
stations, user defined areas and related entities directly. This use case will take 
effect due to create or update activity on the OFC JDIR_BR table. 

Level: 

Sub Functionality 

Pre-Condition: 

a. AREAJTYPS entity pre-populated with all the relevant area types. 

b. Country X-reference entity pre-populated with ERAC 3 char country 
code and VRS 2 char country codes. 

c. LRD_IORGS table populated with all legacy keys to Peoplesoft cross 
reference values 

Success End Condition: 

Stations record created with appropriate referential integrity for all the related 
entities namely USR DFND AREAS, STA UDA. 

Failed End Condition: 

Stations (STNS), Station-UDA (STA JJDA) or User Defined Areas 
(USR DFND AREAS) records could not be created successfullv. 

Primary Actor: 

User responsible for maintaining Branch data. User creating or updating a 
branch record has been shown as a primary actor here, but from architecture 
perspective, the event of that transaction being reflected into OFC_DIR_BR 
table will execute this use case in the form of action. 

Trigger Event: 

New Branch is created or Branch data related to area-hierarchy attributes has 
been updated or Branch has been closed. 
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2.10.1.5 Main Success Scenarios 


2.10.1.5.1 User Creates Branch 


Step 1 - User Creates the Branch record in the OFC J}IR_BR and OFC_WWJ)IR 
tables. 

OFC DIR BR Table 


4BSB, 
s ;; 

fl 

m 


m 


s , 


m 

y 


Column Description 

Column Name 

Data Type 

Value 

Group ID 

Grp Id 

Varchar2(4) 

12 

Branch ID 

Br Id 

Varchar2(4) 

1241 

State Code 

Mail St Cde 

Varchar2(4) 

CO 

Area ID 

Area Id 

Varchar2(6) 

12U 

Region ID 

Regnjd 

Varchar2(2) 

129 

Country Code 

Cntry Iso Cde 

Varchar2(6) 

USA 

Zip Code 

Mail Zip Cde 

Varchar2(18) 

80223 

Phone Area Code 

Ofc Phn Areacde 

Number(3) 

303 

Phone Number Exch 

Ofc Phn Xchng Nbr 

Number(3) 

722 

Phone Last Four 

Ofc Phn Nbr 

Number(4) 

9999 

Long Address Name 

Long^Ad Name 

Varchar2(60) 

Special Sales Denver 

Branch Add Date 

Br Add Dte 

Date 

5/4/2001 


OFC WW DIR Table 


Column Description 

Column Name 

Data Type 

Value 

Group ID 

Grp Id 

Varchar2(4) 

12 

Branch ID 

Br Id 

Varchar2(4) 

1241 

Country Code 

Cntry Iso Cde 

Varchar2(6) 

USA 

Sub-Region ID 

Sub Regn Id 

Varchar2(4) 

12CO 

City ID 

City Id 

Varchar2(4) 



*The record is retrieved by conducting a join on the OFC_DIR_BR and 
OFC WW DIR tables. 


Step 2 - Peoplesoft Cross Reference Values retrieved 

Once the branch data is selected from these two tables, the LRDJORG table is queried 
using the legacy codes and type descriptions (branch, region, group, area, city, sub- 
region) to retrieve the corresponding Peoplesoft values. The following depicts a call to 
theLRD IORG table: 


Select PS_ORG_ID, PS_ORG_DSC from 
LRD IORG 
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Where 

IORGJTYP_DSC = Legacy Type (branch region, group, area, city, sub-region) 
And 

LGCYJORGJD = Legacy Key (for example: VI 09 \ VIA ') 
Step 3 - Create Station Record 

Station record will be created with: 

Station Id: ' 1 00 1 036 ? * Peoplesoft Value retrieved from the LRDJORG Table 
Country Code: 'US' * Will use CountryXreference Table. 
Station name: 'Special Sales Denver' 
Create Date '04 MAY 2001 ' 

Step 4 - Create STAJJDA record showing the area-id and area types for the station. 

This step will create references for this station with all the defined levels of hierarchy. If 
a level of the hierarchy is not defined for a branch then an insert will not be made for the 
record. Note that Peoplesoft key values are used instead of the legacy key values. For 
levels of the hierarchy that do not have corresponding peoplesoft values i.e. area code, 
exchange, zipcode, high zip, the legacy key values are used. As it currently exists, only 
six levels of the hierarchy have corresponding peoplesoft values, group, region, sub- 
region, city, area and branch. 


Stn Id 

Area Id 

Area Type 

Eff Start Dt 

Eff End Dt 

1001036 

US 

ATYCTRY 

Create date on 
OFCDIR_BR 
table 


1001036 

A0012 

ATY_GRP 

Create date on 
OFCJDIR_BR 
table 


1001036 

RGN_COL_99 

ATYJtGN 

Create date on 

OFC_DIR_BR 

table 


1001036 

Missing 

ATYJSUBRGN 

Create date on 
OFCJDIR_BR 
table 


1001036 

CO 

ATYST 

Create date on 

OFCJDIRJBR 

table 


1001036 

AR_COL_012 

ATYAREA 

Create date on 
OFCJDIR_BR 
table 


1001036 

US802 

ATYJiZIP 

Create date on 

OFCJDIRJBR 

table 


1001036 

US80223 

ATYJZIP 

Create date on 
OFC_DIRJBR 
table 
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Stn Id 

Area Id 

Area Type 

Eff Start Dt 

Eff End Dt 

1001036 


A TV PT-RvT AD 

Create date on 
OFCDIR BR 
table 


1001036 

US303722 

ATY XCHNG 

VvICatC Ualc Oil 

OFCJ)IR_BR 
table 


1001036 

101036 

ATY_BR 

Create date on 
OFC_DIR_BR 
table 



*For this record, the branch was not associated with a City hierarchy so no entry 
was made. 

2.10.1.5.2 User Updates Branch 

If any of the area hierarchy related information in OFC_DIRJ8R table is modified, 
corresponding updates need to be reflected on VRS STAJJDA and 
USR_DFND_AREAS table. For the area record that has been modified the sequence of 
events will be as follows. 

Step 1 - Update STAJJDA 

The current relationship mapping a branch to the specific area type will be in-activated by 
updating the effective end date on that record. The new record mapping the branch to the 
new area and AreaJType will be created as in 2.L3 (Step 3) of the use case above. If the 
area with that type does not exist, the new Areajd will be created. 


2.10.1.5.3 User Inactivates a Branch 

All records in the STAJJDA table will be end-dated with the EffEnd J)ate as current 
transaction or system date. 

2.10.1.6 Scenario Extensions 

2.10.1.6.1 User Defined Area does not Exist 

While creating the area references for the newly created station id, the user defined area 
does not exist then the corresponding USR_DFND_AREAS record will be created before 
creating the STAJJDA record. 


•..•r- ; •-•-••< ' • •• 


2.10.1.7 Scenario Variations 

2.10.1.7.1 Region ID not Defined at the Time of Creating a Branch Record 
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If the region id is not populated then the reference to area type 'REGION' will not be 
created. In addition any other area type which is using REGION ID as a prefix for 
uniqueness will not be created. 


2.10.1.8 Related Information 

2.10.1.8.1 Area Types and Level Of Hierarchy 


The values used for the AREA_TYPS table are described here. New attribute called 
Hierarchy will be defined. It will be optional attribute for AREA_TYPS table. 


Description 

Column Value 

Hierarchy Level 

Company 

ATY CMPY 

13 

Country 

ATY CTRY 

12 

Group 

ATY GRP 

11 

Region 

ATY RGN 

10 

Sub-Region 

ATY SUBRGN 

9 

State 

ATY ST 

8 

City 

ATY CITY 

7 

Area 

ATY AREA 

6 

High 3 ZIP 

ATY HZIP 

5 

ZIP 

ATY ZIP 

4 

Area Code 

ATY PHN AR 

3 

Area-Exchange 

ATY XCHNG 

2 

Branch 

ATY BR 

1 
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3 Key Risks, Assumptions, Issues, Dependencies 
3J Risks 

3.1.1 Products and Rates 

• Current analysis and design is based upon the data extracts from three of the 
eighteen ECARS machines. Any significant variations of this data could have an 
impact on the overall design 

3.1.2 Data Bridges / UDA Hierarchy 

• There are no open risks at this time 

3.2 Assumptions 

3.2.1 Products and Rates 

• Orphan rate plans will not be converted 

• Multiple active rate plans can exist at a given location at the hierarchy level 

• ERAC is responsible for the resolution of discrepancies related to conversion of 
data from AS/400 to ECARS SI Oracle database. 

• Records in PLAN_DISC_RATE table will not be converted for iteration 2. 
Applicability of discounts will be addressed as a part of iteration 3. 

• DFLT numbers will be unique within the database. 

• For all conversion areas the data related to the rows indicated as 'Deleted will not 
be converted, i.e. only rows with a RecordStatusCode of <null> and Tnactive 
will be brought over to the VRS database. 
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3.2.2 Data Bridges / UDA Hierarchy 

• An Enterprise region is uniquely identified by composite key of Group id + Region 
id. 

• An Enterprise area is uniquely identified by the composite key of Group id + Region 
id + Area id. In the existing Enterprise data model, an Area ID is comprised of a 
prefix of a two-character group ID and a suffix of a one-character area ID such that an 
area ID of 991 identifies a group ID of 99 and an area ID of 1. For VRS purposes, 
only the third character of an Enterprise Area ID on the OFC JDIR_BR table will be 
used to identify the area. The resulting area ID stored on the VRS STAJJDA table 
would be 993 1 which represents a group of 99 ID, a region of 3 ID and an area ID of 


• An Enterprise branch id is uniquely identified by the composite key of Group id + 
Branch id. 

• Branch unique identifier on ERAC system ie. Peoplesoft key and VRS Stn Jd will 
use the same value so that no separate x-reference table/attribute needs to be 
maintained. 

• Branch data structure and area hierarchy structure (area types and hierarchy levels) do 
not vary based on the country. 

• When creating an entry into the STAJUDA table for an area type of ZIP, only the 
first five digits of the zip code will be used. The data contained in the Mail_Zip_Cde 
column on the OFC_DIR_BR table will be used to determine the ZIP for a branch. 

• All records on the OFC JDIR_BR and OFC_WW__DIR tables will be converted. If 
certain branches (admin, etc) are not to be converted, we need a way to identify these 
records. 


3.3 Issues 

3.3.1 Products and Rates 

• There is no easy way to identify 1 year's worth of history as dates do not exist in 
all the ECARS tables - Resolution: Convert all the history. 

• Any active or deleted rates converted to VRS will be considered expired and will 
not be retrieved by the engines. These will be converted purely from a historical 
perspective. This can cause potential discrepancies between the rates retrieved by 
ECARS legacy and ECARS 2.0 systems 


m 


m 

'hi 

hi 


fli 

0- 
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• ST_DFLT and ZIP JDFLT tables do not have group id to satisfy the linkage to 
DFLTRATE PLAN table. In these cases, the group id will be ignored and only 
one applicable rate plan record will be retrieved for that DFLT number. 


• Do we need to convert CovLimit Amt and FullCovInd fields from 
PLAN_COVJRATE table. There are currently no corresponding fields in VRS 
data model. 


33.2 Data Bridges / UDA Hierarchy 

• We have a need to create or indicate an UM LOCATION. We need to specify the 
attribute which will be used and how this area will be positioned in area hierarchy 

• It is assumed that these transactions will be triggered using Database triggers 
defined on OFCJDIRJBR table. We need to discuss if this is an acceptable design 
option from overall architecture point of view 

• The impact of close branch transaction on remaining data set up needs to be 
evaluated. Eg. Any station-branch level rates defined may need to be in activated 

• We need to discuss the options and constraints necessary to define and maintain 
area id covering requirements related to New York Burroughs area 

• How do we implement the High 3 zip code, zip code, phone area code, and phone 
area code and exchange for non-US countries? 

• There are numerous Legacy Codes that do not currently have corresponding 
peoplesoft values of the LRD JORG table. In addition, there are numerous 
entries that do not have unique peoplesoft values. These deficiencies need to be 
addressed before successful conversion can take place. 
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4 Appendices 
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4.5 VRS Data Model 


/USR DFND AREAS 


STNS 


SSTNJD 
*QT_SEQ 

*CREAT BY 
*CREAT DT 

*cry awiupjowjcd 
*dlvravlflg 

*GLTJSEQ 

ins prcmded.cd 
*lgg lang_cd 
uve stn_jFd 
*min age for_cash 
*orr org id 
*part1cp level_nbr 
♦settle ccj=lg 
*shtl svc type_cd 
*stn act typ 

*ATNj^UTOJ=LG 
*STN CAT 
*STN LOCTYP 
*STN NAME 
*STNSTAT 
*STM_STOPSL FLG 
*STN_TYPE 

*tmz 

*res srchjlg 

*ORRjORGJD RESP 

*ORR ORT ROLE TYP CD RESP 


#ATY_AREA TYP 
#AREAJD 

*AREAJDESC 
*CURR CD 
IWCNTL IND 
VPA_VPAJND 
CITY ALIAS FLG 



UDA OF- 


AREA TYPES 
#AREA TYP 
*AREA_TYP ACT 
AREA TYP DESC 
AREA TYPJSHRT DESC 
DATES REQ FLG~ 
HIERARCHY LVL 


STA UDA FK 


STA UDA 



STAJJDAFK2^— 


#STNJD1 
#AREA_ID2 
#AWJ«EAjrYP2 
#EFF_jSTART_DT 
EFF END DT 


* Non bolded fields indicate that these are optional attributes for these entities. They are 
supported by VRS data model. At this time no specific use or business rule has been 
defined for ERAC implementation. 
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4.6 UDA Hierarchy - Use Case Diagram 



=nd2 -End7 

CreateBranch 


:d5 


A 

User 


1: 


nQ3 



-4nd4 ^ -End9 

UpdateBranch 



•qnd6 ^ -End11 

CloseBranch 



System 


«US3S» 



CreateStaUdaAndUda ] 


3nds» 


-End8 



«uses» 

' CreateStation ) — IX CreateStaUda] 



-End10 



UpdateStation, 


&uses» 


-End12 




«uses» 
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Equipment 

Currently, Enterprise can price coverages and additional 
products (ancillary items) for a specific rate plan or bill 
type. VRS does not support this function. Alternate 
proposal is to allow pricing coverages and additional 
products by location and default type. Station level values 
will be used if no entry is available for a given location and 
default type. 

91 

Equipment 

Enterprise car class definition is potentially composed of 
two components: a car class and a car class suffix. VRS 
rate detail does not support any sort of car class suffix. 
ERAC needs to support 8 character vehicle car class plus 4 
car class suffix 

1 119 

Equipment 

Special equipment charges could be defined as weekly, 
monthly rate. 

122 

Equipment 

Support additional vehicle features that are priced 
separately from the vehicle rate at the station level. 
Examples of these features are snow tires, Onstar system 
and so on. 



['{Primary Document Owner/Domain 


Issued by: (PSC) 






Nitin Palsule 

Manager Rate Engine/Sub 
Engines 








Customer Approval 


Authorized by: (ERAC) 


Name ;v - : ;v 

f Posi^ 












Last Save Date:l 1/5/2001 10:34 AM 


Page 3 of 23 


Equipment Engine Detail Design_I3 (2) 


rent-a-car 


ECARS v2.0 - Accurate Out the Door Pricing 
Detailed Design Specification 


Document History 


Version 

' '.' Date 



1.0 

05/14/01 

Tom Brayman 

Initial draft of Design Document 

1.1 

06/05/01 

Tom Brayman 

Added UDA at station level 

2.0 

09/10/01 

Robert Srodulski 

Added all Addendum information to baseline 
document. 

2.1 

11/05/01 

Robert Srodulski 

There were no functional impacts and/or 
Addendums for Iteration 3 - Equipment 
Engine. 


y 
f 3 


m 


l s 5 


t :■ 

pa 

Ki- 
te* 


■ -tar r 


Last Save Date: 11/5/2001 10:34 AM 


Page 4 of 23 


Equipment Engine Detail Design_I3 (2) 



1.1 Overview 


The purpose of this document is to provide detailed design specifications of how the Equipment 
Engine component of the Vehicle Rental System (VRS) will be utilized in providing equipment types 
and charges in the retail line of business. This will reflect the complete design at a high level with 
reference to the gaps that will be delivered in iteration 2. This document is specifically for the 
equipment engine. 

In VRS (Vehicle Rental System) Equipment Types (EQP_ITEMJTYPS), Equipment Charges 
f (EQP _CHGS), and Branch Equipment Charges (STN_EQP_CHGS) are the main entities used to 
SI satisfy the special equipment related requirements of a rental transaction. 

Is: I 

m 

p| These entities allow users to classify and associate a set of standard and customized equipment Types 
Qj and associate them with the combination of product type, and/or product instance, location and 
SSI vehicle category. 

:W : lThe Equipment Engine in VRS is used to retrieve the set of applicable Equipment Types and charges 
I for a specified set of input parameters. 

m 

l||The design details of these data base entities and associated engine functionality as it applies to the 
jpRetail-SI business type of ERAC ? are described in the following sections. 

!^1.2 Dependencies 

Dependencies with ERACs Test windows. 

1.3 Data Conversion 

High level impacts to Data Conversion. A separate document will be published for data conversion 
design. 

1.4 Impact Analysis 

This section is not applicable for Iteration 2. This section will be relevant for subsequent iterations 
to track the differences between iteration 3 and 2, iteration 4 and 2 and so on. 
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2.1 Equipment Engine 


2.1.1 Equipment Types Use Case 

The following defines information that pertains to this particular use case. Each piece of information 
is important in understanding the purpose behind the Use Case. VRS manages the master list of 
special equipment that is available to the application by association with a charge type. This list is 
stored in the Equipment Item Types table. 


Goal In Context: 


Scope: 


pa 

Hi Level: 


I Pre-Condition: 
H Success End Condition: 


las 


J Failed End Condition: 
Primary Actor: 


si 5 


m 


An ERAC user maintains the Equipment Types in the ECARS 
Equipment Item Types table. 

This Use Case deals with the Insert/Update activity on the 
Equipment Item Types table. 
Sub functionality 

1 . RRA_CHG_TYPS pre-populated with all relevant charge 
types. 

An Equipment Item Type record is created with the appropriate 
database constraints defined for an Equipment Item Type Entity. 
The Equipment Item Type Record is not created. 

The main actor is the User responsible for maintaining this 
information. 

A Requirement to create a new Equipment Item type. 


I Trigger Event: 

i. 

^2.1.1.1 Main Success Scenario Create Equipment Item Record 


■5SS 3 


The equipment item types entity stores unique special equipment id's for a specific equipment type. 
ERAC specifies the charge type for the equipment and a detailed description of the special 
equipment. The pricing of the equipment is covered in separate use case documents dealing with 
branch or product related equipment charges. 

The details of how these different Equipment Item types are structured within the VRS data model is 
explained below: 

Step 1: User Creates the Equipment Item Type record in EQPJTEM JTYPS table. 

In the VRS data model, the EQPJTEMJTYPS table stores all the valid special equipment type 
codes. Each special equipment type can be described using a 35 char wide text field called 
spcl_eqp_desc. In addition, for each equipment type, there is valid pre-defined charge type value 
associated with the record. The Charge Engine uses this field at the time of tax calculation and 
charge allocation. 
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The key attributes and some representative values are shown in the table below: 


Special 

Equipment 

ID 

Special Equipment Type 
Description 

Charge 
Type 

BST 

Booster Seat 

00067 

CST 

Child Seat 

00068 

CSI 

Infant Seat 

00069 

SKV 

Ski Rack 

00072 

PHN 

Cell Phone 

00071 


2.1.1.2 Related Information 

Below is the information related to the record in the RRAJZHGJTYPS table that is referenced from 
the EQPJTEMJTYPS table above: 


ri 


Charge 
Type 

Description 

Charge 
Category 

Taxable 

00068 

CHILD SEAT - SPECIAL EQUIPMENT 

SPE 

Y 

00072 

SKI RACK - SPECIAL EQUIPMENT 

SPE 

Y 

00071 

CELL PHONE - SPECIAL EQUIPMENT 

SPE 

Y 


□The details of how the charge types associated with the Equipment Types will be covered in the Tax 


yknd Surcharges Document. 
2.1.2 Equipment Charges Use Case 


3! 

s . .. 


n fin VRS, the Equipment Charges table will be used to associate bundled products with special 
pjequipment. These bundled products have a date range associated with there availability. This use 


please explains the design details of the equipment charges information. 
Goal In Context: 


Scope: 
Level: 

Pre-Condition: 

Success End Condition: 

Failed End Condition: 
Primary Actor: 
Trigger Event: 


ERAC user maintains the Equipment Charges in the ECARS Equipment 
Charges table. 

This Use Case deals with Insert/Update activity on the Equipment 
Charges table 
Sub Functionality 

EQPJTEMJTYPS table pre-populated with all relevant Special 
Equipment Type information. 

PRODJNSTS table pre-populated witli Product instance code. 
Equipment Charges record created with appropriate database constraints 
defined for Equipment Charge Entity 
Equipment Charge Record not created. 

The main actor is the User responsible for maintaining this information. 

User who wants to change the equipment charges or the equipment 
charges attributes. 
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2.1.2.1 Main Success Scenario - Creates Record for Bundled Equipment Charge 

The equipment charges entity stores unique equipment charge sequence for a specific equipment 
type. ERAC specifies the product code and the list of included equipment is displayed for that 
product instance, if applicable. The user can define additional equipment for the product instance by 
specifying the special equipment code, the reservation start and end date, the rental start and end date 
and the unbundled daily amount. The reservation start and end date, rental start and end date, 
product instance and product version are a constraint used by the equipment engine to return the 
available bundled equipment details. The applicable status indicator defaults to "I" for included and 
can not be changed. The special equipment code is available from a list of values based on the 
values in EQP_ITEM_TYPS table. 

The details of how these different Equipment Charges are structured within the VRS data model is 
explained below. 

f j Step 1: User Creates the Equipment Charge record in EQP_CHGS table 


ill In the VRS data model, the EQP_CHGS table stores the attributes of the special equipment based on 
|jproduct instance. Each equipment charge has a reservation start and end date and a rental start and 
|I end date that the equipment is available for that product. In addition, for each equipment charge, 
,* (there is an unbundled daily amount that specifies how much to charge for the equipment. 


.Some of the key attributes and their values are shown below: 


Equip 
MjJhg Seq 

EQP 
ID 

Pickup Date 

Return Date 

Res Strt 
Date 

Res End Date 

Unbld 

Dally 

Amt 

AppI 

Status 

Ind 

Prod 

Inst 

Code 

HI 

BST 

15-May-2001 

31~Dec-2037 

15-Mav-2001 

31-Dec-2037 

3.00 

I 

ALTW 


CST 

15-May-2001 

31-Dec-2037 

15-May-2001 

31-Dec-2001 

4.00 

I 

ALTW 

3 

PHN 

15-May-2001 

31-Dec-2037 

15-May-2001 

31-Dec-2037 

5.00 

I 

USSD 
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2.1.3 Branch Equipment Charges Use Case 

In VRS, the Branch Equipment Charges table will be used to specify prices for each type of special 
equipment offered at a branch or at the hierarchy level of the location for the pricing purpose.. This 
use case explains the design details of branch equipment charges information to satisfy the 
equipment requirements of Enterprise's business. 

Goal In Context: ERAC user maintains the Branch Equipment Charges in the ECARS 

Branch Equipment Charges table 
Scope: This Use Case deals with Insert/Update activity on the Branch 

Equipment Charges table 
Level: Sub Functionality 

Pre-Condition: EQPJTEMJTYPS table pre-populated with all relevant Special 

Equipment Type information, 
i. = STNS table pre-populated with Branch ID. 

!«! Success End Condition: Branch Equipment Charges record created. 

g ! Failed End Condition: Branch Equipment Charges Record not created. 

it I 

J jj J Primary Actor: User responsible for maintaining Equipment data. 


5 3 


Trigger Event: User who wants to change the special equipment charges or the 

S J equipment charges attributes at a specific branch. 

yl 

ii 2.1.3.1 Main Success Scenario - Creates Record for Branch Equipment Charges 

RjStep. 1: User Creates the Branch Equipment Charge record in STNJEQP_CHGS table 


i«5. 
AM 


JThe branch equipment charges table is used to associate special equipment (i.e. PHN, CST, etc) to a 
□particular class of product type, branch and car class and any other hierarchy class level where the 
"rate is being defined, and determine specific prices. The equipment is available for all vehicle 
classes (AC AR) unless a specific vehicle class is defined. The special equipment must first be 
defined in the EQPJTEMJTYPS table before the branch equipment charges attributes can be 
defined and the branch must exists. The daily amount and the max per rental amount are required for 
setup. The max per rental amount will be used to check for optimization if it is specified. 
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3.1 Equipment Engine Processes 



mtk.*- Mm 


The equipment engine is a tuxedo service, which is called when information related to equipment 
details is required. Equipment engine is called internally by the rate search service if specific vehicle 
category code is provided at the time of the call. API for calling the equipment engine is exposed to 
the external systems so that it can also be called directly if user selects the vehicle category after rate 
search call and does not wish to obtain the list of valid equipment for the rental. 

3.1.1 Inputs 

The following parameters are displayed in the order that they are needed. All Parameters must be 
•sent. The mandatory/optional flags represent which information must be filled in for the Equipment 
jEngine to return the correct equipment details and rates. 









ys^ ; ' : - 

•s£ §|i " fir at r~" t*j hi * Z i 


Technm^ 

\ Standard Header 

The content of this header will be used for 
debugging, user test support, performance 
monitoring, tuning and error ioqqinq 

refer to standard header document 
for layout and population rules 

Mandatory 



eqengtvOOl version 

Identification string for this TUX interface 

FN_EQENGTV001 VERSION 

Optional 

char 

100 

, resjmsp 

Reservation Timestamp format 
YYYYMMDDHH24MI 

FN_MEN_RES_TMSP 

Mandatory 

char 

13 

:co__stn id 

Station (Branch) ID of DickuD location 

FN MEN CO STN ID 

Mandatory 

char 

11 

j eojmsp 

Pickup Timestamp format 
YYYYMMDDHH24MI 

FNJAENJX>JTMSP 

Mandatory 

char 

13 

] cijmsp 

Return Timestamp format 
YYYYMMDDHH24M1 

FN_MEN_CIJTMSP 

Mandatory 

char 

13 

eqp list 

List of specific products or ALL or FREE 

FN MEN EQP LIST 

Mandatory 

char 

160 

billing cycle 

Calendar day 'C or 24 hour 'H' rate 

FN MEN BILL CYCLE 

Mandatory 

char 

1 

prod type 

Product Type ('R'etail, ...) 

FN_MEN PROD TYP 

Mandatory 

char 

1 

prodjosTcd 

Code to relate it to a particular product 
instance 

FN_MEN_PRODJNST_CD 

Optional 

char 

9 

prod inst ver 

Version number of the product instance 

FN MEN PROD INST VER 

Optional 

long 

4 

cat cd 

Vehicle Category Code ] 

FN MEN CAT CD 

Mandatory 

char 

9 

cat cd suffix 

Suffix vehicle cateqory 

FN MEN CAT CD SFX 

Optional 

char 

5 

ci_grace_mins 

Number of grace minutes allowed for 
vehicle return. 

FN_MEN_CIJ3RACE_MINS 

Optional 

long 

4 

curr tab 

Exchange Rate Type. 

FN MEN CURR TAB 

Optional 

char 

11 

co curr 

Pickup Branch Currency 

FN MEN CO CURR 

Optional 

char 

4 

area ids 

ListofUDA's 

FN MEN AREA IDS 

Optional j 

char 

1000 


y 


VRS currently uses the first field of in an input buffer eqengtvOOl ^version to validate if caller and the service are using 
the identical version of the input and output buffers. 

Return date is mandatory from Equipment engine perspective. If the return date is not known at the time of transaction 
Client process will add 1 day to the pickup date before making the Equipment engine call 
Product type is 'Mandatory for e R 'etail type of transaction at this stage. 
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3,1.2 Outputs 

Equipment engine returns the list of special equipment and associated attributes for the specified 
rental The output structure for this service and the associated details for the structure elements are 
described below. 

If engine error field is anything other than ' 0' zero, then the results of the output buffer are 
undefined. 


Record count indicates the number of equipment records returned for this call. The remaining fields 
in the output list after this field have multiple occurrences as indicated by the record count. The 
equipment code is returned along with a description of the equipment. The applicable charge type 
follows along with the vehicle category code the equipment is available for. The equipment amount 
is expressed in terms of hourly amount, daily amount, weekly amount, monthly amount, max amount 
I**, per rental, and a per rental amount. Corresponding charge frequencies for each of the amount 
f J follows these. The charge frequency is optimized based on the values defined for various charge 
O amounts (daily, weekly, monthly) only if the max per rental amount is specified. The Totals field is 
Wthe total cost of selecting that equipment for this rental. The Included flag is Tncluded. 



eqengtv001_yersion 


Identification string for this TUX 
interface 


FN_EQENGTV001_VERSION 


Optional 


char 100 


engme_error 


Error code returned 


FN EEN ERR STATUS 


Mandatory 


ong 


err text 


Error Text Returned 


FN EEN ERR MESSAGE 


Optional 


char 


81 


m 


Number of Records 
( 0-40 ) 


Number of Equipment records 
returned 


FN EEN REC COUNT 


Mandatory 


ong 


eqp_id 


Equipment IP's 


FN EEN EQP ID 


Mandatory 


char 


eqp„desc 


Equipment Description 


FN EEN EQP DESC 


Mandatory 


char 


36 


commjjvcjlg 


Comm Device Flag 


FN EEN COMM DVC FLG 


Mandatory 


char 


40 


rntjshgjyp 


Charge Types 


FN EEN EQP RNT CHG TYP 


Mandatory 


char 


cat cd 


Category Code 


FN EEN CAT CD 


Mandatory 


char 


cat cd suffix 


Suffix vehicle category 


FN MEN CAT CD SFX 


Mandatory 


char 


mt amt 


rnt cnt 


Rental Amounts 


FN EEN EQP RNT AMT 


Mandatory 


double 


8 


Rental Counts 


FN EEN EQP RNT CNT 


Mandatory 


£Qfl. 


repl_cost 


Replacement Cost 


FN EEN EQP REPL COST 


Mandatory 


double 


8 


hr mt amt 


Hourly Rental Amounts 


FN EEN EQP HR RNT AMT 


Optional 


double 


hr cnt 


Number of Hours to charge 


FN EEN EQP HR CNT 


Optional 


i°I!S_ 


dyjrnt_amt 


Daily Amounts 


FN EEN EQP DY RNT AMT 


Optional 


double 


8 


dy„cnt 


Number of days to charge 


FN EEN EQP DY CNT 


Optional 


long 


4 


wk mt amt 


Weekly Rental Amounts 


FN EEN EQP WK RNT AMT 


Optional 


double 


8 


wk cnt 


Number of weeks to charge 


FN EEN EQP WK CNT 


Optional 


long 4 


mo mt amt 


mo cnt 


Monthly Rental Amounts 


FN EEN EQP MO RNT AMT 


Optional 


double 


Number of months to charge 


FN EEN EQP MO CNT 


Optional 


long 


8 


4 


tot rnt amt 


Calculated Totals 


FN EEN EQP TOT RNT AMT 


Mandatory 


double 


8 


max rnt amt 


Max Charge per Rental Amount 


incl_flg 


included Flags 


partjflg 


Part Flag 


FN EEN EQP MAX RNT AMT 


Optional 


double 


8 


FN EEN INCL FLG 


Mandatory 


char 


FN EEN PART FLG 


Mandatory 


char 


unbld, dy_rnt _amt 


Unbundled Daily Rental Amount 


FN EEN UNBLD DY RNT AMT 


Optional 


double 


8 
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3.1.3 Detailed Process Flow 

The Equipment Engine provides valid equipment details and charges for a rental based on product 
type selected, vehicle category and pick up location. There are three different call modes for the 
Equipment Engine. The call modes are: "ALL", "JFREEJ' or a specific list of equipment types. 
The ALL mode is used to return all equipment available at a branch. The "JFREE J' mode is used to 
return all free (bundled) equipment available at a branch. The Equipment Engine will return all valid 
equipment and charges up to 40 for each call mode and the applicable charge for hourly, daily, 
weekly, monthly, or per rental amounts for each equipment type and the GUI will determine whether 
to apply daily, weekly, monthly or per rental charges on the transaction. 

The Equipment Item Types table combined with the Station Equipment Charges tables contains the 
information needed to return the proper special equipment available based on vehicle category and 
branch id. 

a. , 
Sis) is 

h I Each Pickup Location may not have equipment information set up at the Branch Level This requires 
IS I that the Equipment Engine traverse through the 1 1 levels of Rate Hierarchy list for the specified 
III pickup location starting with the lowest level. The traversal of the rate hierarchy is stopped, when 
fjj.one or more valid equipment types are found at a particular level. The equipment types will not be a 
H composite of each level, 

111 

: "Refer to the use case document on the UDA-Rate Hierarchy for additional details for the rate 
^hierarchy. 

Ill 

r||The first step is to locate the branch record within the STAJJDA table using the Branch ID. Once 
©located the additional information required for the hierarchy search would now be available. The 
©STAJJDA table may contain a record for each level of the hierarchy that the branch is associated 
J^with. 

The Equipment Engine formats the pick up and return timestamps, to a standard date format and then 
calculates the rental duration in number of days and hours, taking grace minutes into consideration. 

If the product is specified in the inputs, the bundled equipment is retrieved for the product specified. 
A constraint is placed on the selection of the bundled equipment. The Equipment Types table 
combined with the Equipment Charges table contains the information needed to return the proper 
equipment for the calling location. 

The bundled equipment selection must be available based on the input pickup and reservation dates 
against the values setup in the Equipment Charges table. The following details how to find the list of 
applicable bundled equipment for the specific rental: 
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PRODUCT = :prod_inst_cd 

co Jmsp between the Start Date and End Date 

resjmsp between Reservation Start Date and Reservation End Date 

Each Branch may not have any special equipment defined at the Branch Level. In this case, the 
bundled equipment list is empty. 

The equipment list is prepared to make the selection of the available equipment for the branch and 
vehicle class combination. The equipment list can have the following values: 


Equipment List 

Meaning 

ALL 

Ail equipment available 

FREE 

Free (bundled) equipment available 

CST|BST|PHN|... 

Specific equipment list 


I** The _FREE_ equipment list will return the equipment details for all the bundled equipment defined 
p for the product instance specified. The equipment ids are retrieved based on the follow conditions: 
G) Product Instance = Input Product Instance and 

Of Pickup date must be between the EQPJ3HGS,start_date and EQP_CHGS.end_date and 

|| Reservation date must be between EQP_CHGS.res_start_date and EQPJ3HGS.res_endjiate 

5* j Once the equipment ids are return, the list is parsed out to retrieve each equipment type. 

|" If a specific equipment list is given, the list is parsed out to allow each equipment type to be selected. 

S?St3 

ill The branch specific equipment details and charges are gathered based on the equipment list, branch 
m and vehicle class. The Equipment Types table combined with the Branch Equipment and Branch 

Equipment Charges table contains the information needed to return the equipment details and 
: W charges for the calling location. 

If the equipment list is ALL, the following conditions must be meet in order for the equipment to be 
available: 

Branch = Pickup Branch and 

Vehicle Category = catted or "ACAR" and 

Product Type -"R" and 

Allocated Quantity > 0 and 

Pickup Date must be between Stop Sell Start Date and Stop Sell End Date and 
Pickup Date must be between Start Date and End Date and 
Equipment Status = "F" or "R" or 

if Equipment Status - "S" then the Stop Sell Over ride Days < Rental Duration Days 

For _FREE_ and specific equipment list, in addition to the conditions above, the following condition 
must be meet in order for the equipment to be available: 
Equipment Id in Equipment List. 
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Rate Engine 


Equipment 
Main 


Start 


I Input Structure 


Minimum Parameters 

Reservation Timestamp 
Pickup Branch ID 
Pickup Timestamp 
Return Timestamp 
Equipment List 
Country Code 
Vehicle Category 
Vehicle Suffix 
Product Type 
Product Instance 
Billing Cycle 
Checkin Grace Minitues 


Output Structure 


Calculate 
Rental 
Length 


Gather 

Prepare 

Bundled 

Equipment 

Info 

List 


Gather 
Equipment 
Details 


Create 
Output List 


Calculate 
Rental 
Duration in 
Pavs&Hrs ^ 


, Return Rental 
j Duration 


Retrieve bundled equip 
from EQP ITEM TYPS 
and EQPJ3HGS tables 


Return Bundled Equipment 


Equipment List can be: < 
"ALL" all equipment available 
■ FREEJ' for all free equipment 
H CST|BST|PHN" or specific 


Prepare Equipment 
List based on input params 


Return List of Equipment 


Up to 40 

Engine Error 
Record Count 
Equipment Id 
Equipment Description 
Comm Device Flag 
RNT Charge Type 
Vehide Cat Code 
Rental Amount 
Rental Count 
Replacement Cost 
Hourly Rental Amount 
Hourly Count 
Daily Rental Amount 
Daily Count 
Weekly Rental Amount 
Weekly Count 
Monthly Rental Amount 
Monthly Count 
Total Rental Amount 
Max Rental Amount 
Included Flag 
Part Flag 
Unbundled Daily Rental Amount 


Return 


Get Equipment 
Details for the 
Specified input list 


Retrieve Equipment Details 


Return Equipment Details 


Reorganize output 
equipment list to match 
input equipment list 


Move Equipment Details list to the output structure 


Return Filled Output structure 


Move items to 
output structun 
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3.1.3.1.1 Individual Scenarios 1 

Scenario 1: Rental is being made for the location 0109 with vehicle car class of ECAR 


Input Parameters: 
Branch 
Res Date 
Pickup Date 
Return Date 
Equipment List 
Product Type 
Product Instance 
Vehicle Cat 
Cat Cd Suffix 
Grace Minutes 


0109 

200107011000 
200107011000 
200107081000 
BST|CST|PHN 
R 

ALTW 
ECAR 
Null 
0 


HThe output lists all equipment available for specific vehicle category. The output list also shows that 
Othe optimization is being done for BST and CST with the charge frequency based on the daily, 
|«! weekly, monthly amounts available for equipment and the length of rental as indicated by the input 
^parameters. There is no optimization on the PHN because the max per rental amount is not 
^applicable. 


n 


jThe output records returned would be: 


m 

S 1? 

11 1 


Field 

Value(s) 

Engine Error 

0 

Record Count 

3 

Equipment ID's 

BST 

CST 

PHN 

Equipment Description 

booster seat 

child seat 

cell phone 

Comm Device Flag 

N 

N 

N 

Charge Type 

0067 

0068 

0071 

Category Code 

ECAR 

ECAR 

ECAR 

Suffix vehicle category 




Rental Amount 

25.00 



Rental Count 

1 

1 

1 

Replacement Cost 

100.00 

100.00 

155.00 

Hourly Rental Amount 


1.00 


Number of Hours to charge 

0 

0 

0 

Daily Amounts 

5.00 

5.00 

5.99 

Number of days to charge 

1 

1 

1 

Weekly Rental Amounts 


35.00 

35.00 

Number of weeks to charge 

0 

0 

0 

Monthly Rental Amounts 




Number of months to charge 

0 

0 

0 
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Field 

Value(s) 

Totals 

5.00 

5.00 

5.99 

Max Charge per Rental Amount 

50.00 

75.00 


Included Flags 

I 

I 

I 

Part Flag 

Y 

Y 

Y 

Unbundled Daily Rental Amount 





3.1.3.1.2 Individual Scenario 2 

Scenario 2: Rental is being made for the location 0109 with vehicle car class as ECAR 


la? I 
111 

■Pi 

IB;.? 

% § 


Input Parameters: 
Branch 
Res Date 
Pickup Date 
Return Date 
Equipment List 
Product Type 
Product Instance 
Vehicle Cat 
Cat Cd. Suffix 
Grace Minutes 


0109 

200107011000 

200107011000 

200107081000 

_FREE_ 

R 

B213 
ECAR 
Null 
0 


« In this case, only the bundled equipment for the specified vehicle category and product instance is 
l^returned. The output records returned would be: 


m 

mi 


Field 

Value(s) 

Engine Error 

0 

Record Count 

1 

Equipment ID's 

PHN 

Equipment Description 

cell phone 

Comm Device Flag 

N 

Charge Type 

0071 

Category Code 

ECAR 

Suffix vehicle category 


Rental Amount 


Rental Count 

1 

Replacement Cost 

155.00 

Hourly Rental Amount 


Number of Hours to charge 

0 

Daily Amounts 

5.99 

Number of days to charge 

1 

Weekly Rental Amounts 

35.00 

Number of weeks to charge 

0 

Monthly Rental Amounts 
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Field 

Value(s) 

Number of months to charge 

0 

Totals 

5.99 

Max Charge per Rental Amount 


Included Flags 

I 

Part Flag 

Y 

Unbundled Daily Rental Amount 

1.95 
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4 A Risks 

4.2 Assumptions 

43 Issues 

43.1 Zero as a valid value 

M During the detailed design review it was indicated that zero could be a valid value for any of the 
O charge amounts. VRS currently uses zero in charge amount to indicate the presence of null We need 

};* to agree on another convention for VRS engines to communicate presence of null. 

liJ 
o| 

p 4.3.2 All Equipment Charges will be line item 

hi During the detailed design review it was indicated that special equipment for Europe might be billed 
V- as a blended rate. Our recommendation is for Europe to use individual access code to create blended 
N* rates. The VRS system will compute all equipment charges not created this way as a line item. 

Ml : 

H\ 
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Need ability to associate general conditions by some 
combination of location and default type. 

91 

General Conditions 

Enterprise car class definition is potentially composed of 
two components: a car class and a car class suffix. VRS 
rate detail does not support any sort of car class suffix. 
| ERAC needs to support 6 character vehicle car classes. 
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1 Introduction 




1.1 Overview 

The purpose of this document is to provide detailed design specifications of how the General 
Conditions Engine component of the Vehicle Rental System (VRS) will be utilized in providing 
messages in the retail line of business. This will reflect the complete design at a high level with 
reference to the gaps that will be delivered in iteration 2. This document is specifically for the 
general conditions engine. 

In VRS (Vehicle Rental System) General Conditions (GENCNDS) and Rental Conditions 
H(RNT_CNDS) are the two main entities used to satisfy the messaging related requirements of a rental 


transaction. 


Pl-These entities allow users to classify and associate a set of standard and customized General 
ft Conditions and associate them with the combination of product instance, distribution channel, 
Si location based rate hierarchy and vehicle category through the use of a Rental Condition. 

if 1 The General Conditions Engine of VRS is used to retrieve the set of applicable conditions for a 

h k specified set of input parameters. 

W 

ft The design details of these data base entities and their associated engine functionality as it applies to 
1] the Retail-SI business type of ERAC, are described in the following sections. 

i . 

1.2 Dependencies 

Dependencies with ERAC's Test windows. 

1.3 Data Conversion 

A separate document will be published for data conversion design. 

1.4 Impact Analysis 

The primary, difference between iterat i on. 7. and 3 is the introduction of the product type code field. 
I^r^ introduced but not im plemented in iteration 2. the distribution channel will be 
im plemented in this iteration. 
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2.1 General Conditions Engine 


£3 


The Data Components/Setup for the General Condition Engine is the same as iteration 2. However, 
the VRS system will be enhanced to accommodate the NATRES rate rule system. There are five 
types of rate rules: Deposit Rule, Guarantee Rule, Mileage Rule. Miscellaneous Rule, and 
Pickup/Return Rule. This document will address the first four. Pickup/Return Rules will be 
implemented with VRS Rate Oual. This topic is addressed in another document. The rate rules are 
associated to a group and branch combination (area id). Within a specific group/branch combination, 
rules are farther broken down by car class and rate plan code. Each rule has an effective start and 
ygnd date and a rule code that maps to the rule description in the rate rule header file. The rule 
descriptions are broken down into the four rate rules mentioned above. Each rate rule detail file 
Contains the specific data for the four types of rules listed above and is retrieved using the rule type 
land rule code. 


l.l.l General Conditions Use Case 


f ^The following defines information that pertains to this particular use case. Each piece of information 
Lis important in understanding the purpose behind the Use Case. 


w V. Goal In Context: 


Scope: 
Level: 

Pre-Condition: 
Success End Condition: 
Failed End Condition: 
Primary Actor: 
Trigger Event: 


Retail products can have related conditions based on branch location. When a 
general condition is created, the data will be added to the General Conditions 
(GEN_CNDS) table. 

This Use Case deals with Create activity on the general conditions table 
(GEN_CNDS). 

CG_REF_CODES table populated with Type domain values 

General condition record created. 

General condition not created successfully 

User responsible for maintaining general condition data. 

New general condition is created. 
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2.1.1.1 Main Success Scenario 


Scenario: User Creates New General Condition 


In VRS, the messages associated with the rental are implemented using two tables: GEN_CNDS 
(General Conditions) and RNT CNDS (Rental Conditions). The General Conditions table defines 
the types or classes of messages and allows the user to add the text describing the general condition. 
The Rental Conditions table allows a user to specify a detailed message for a particular general 
condition type (see types below) and associate it with the combination of product instance, 
distribution channel, station, UDA-based rate hierarchy and vehicle class definition. 

There are three steps in creating a General Condition: 

Step 1: User defines the type of general condition to create. Currently for VRS, the type must be one 

hkyf the following domain values: 

pi 

&\ 


rii 

m 
O 


si 


AGE 

PAYMENT 

BEST RATING 

PROMOTION PRODUCTS 

BLACKOUT 

PUBLIC PRODUCTS 

COUPON 

REFERENCE 

COVERAGES 

REFUELING 

DLVCOLL 

RESTRICTION 

ELIGIBILITY 

RETAIL 

EQUIPMENT 

SERVICE 

FREESELL 

TAXES 

FUEL 

TRAVEL PROGRAMS 

GUARANTEE 

UPSELL 

GUARANTEE RES 

DEPOSIT 

MX RENTALS 

MILEAGE 

NOSHOW 

MISCELLANEOUS 

ONEWAY 



The Type domain values shown above are representative of the types currently supported by VRS. 
The domain values can be configured to reflect the Enterprise way of classifying the 2 lines of SI text 
currently in use. In order to accomplish this, a new domain value can be added to reflect the 
requirement to display these two lines of text. The domain values are found on the 
CG REF CODES table. 


Step 2: User provides general condition Lines 1-30. At a minimum, Line 1 (CND_LN1) must be 
supplied. 


Last Save Daterl 1/1/2001 9:12 AM 


Page 7 of 27 


General Conditions Detail Design_I3 


Enterprise 


rent-a-car 


ECARS v2.0 « Accurate Out the Door Pricing 
Detailed Design Specification 


perotsystems* 


Step 3: User saves the record. The row is created in the general conditions (GEN_CNDS) table. 
The primary key for this record is the condition ID (CNDJD). The condition ID is an Oracle 
generated sequenced value. 


Column Description Column Name 


Data Type 


#Condition ID 
Condition Type 
Condition Line 1 

Condition Lines 2-30 


CNDJD Number(6) 

TYP Varchar2(20) 

CNDJLNl Varchar2(75) 

CNDJLN2-CNDJLN30 Varchar2(75) 


to" 

-;?! 


* Bolded fields represent mandatory attributes for General Condition's entity. 

The following data is provided by a user to create a general condition: 

Condition Type: REFERENCE 
Condition Line 1 : Do not offer vehicle upgrades 
Condition Lines 2-30: <BLANK> 


pi 

y fThe following record will be added to the general conditions table (GEN_CNDS): 


i Condition ED 

Condition Type 

Condition Line 1 

Condition Line 2 

620 

ELIGIBILITY 

To be eligible for this rate, renter must be 
resident of Australia 


631 

AGE 

Renter must be 2 1 years or older to rent 
Young renter fee does not apply. 


; 645 

SERVICE 

If customer waits more than 45 minutes for 
a vehicle 

Apply a $25 courtesy 
adjustment 

s 648 

AGE 

Renter must be 25 years or older to rent 


655 

REFERENCE 

Do not offer vehicle upgrades 



f * Bolded row represents new entry for iteration 3 


2.1.1.2 Update of a General Condition 

The only information that can be updated for an existing general condition is Condition Lines 1-30. 
An existing line may be modified or a new line may be added to the record No other updates may be 
made to the record. In order to update or add a line, the user selects the record and makes the 
modification or addition. 

2.1.1.3 Deletion of a General Condition 

A user does not have the ability to physically delete an existing general condition if it is attached to a 
rental condition. The general condition can be deleted if and only if it is not attached to a rental 
condition. 
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2.1.2 Rental Condition Use Case 

In VRS, the rental conditions (RNT_CNDS) table will be used to associate a General Condition with 
Products and/or Contracts at the specific location or at the hierarchy level of the location. This use 
case explains the design details of rental conditions information used to satisfy the messaging 
requirements of Enterprise's retail business as defined in iteration 2 of the project scope document. 

Goal In Context: Relate a General Condition to a product type and location 

Scope: This Use Case deals with Create activity on the rental conditions table 

(RNTCNDS). 
Level: Sub Functionality 

Pre-Condition: 1. Branch inserted into appropriate User Defined Area entity and 

populated with all the branch data. 

2. User Defined Area entity populated with the appropriate area Jd' s 

3 . General Condition exist on GENCNDS table 

4. Product instance entity populated with product instances 

5. Product Types entity populated with product types 
Success End Condition: Rental condition record created with appropriate referential integrity for all 

the related entities such as general conditions, UDA's, vehicle categories and 
product instances 

Failed End Condition: Rental condition not created successfully 
Primary Actor: User responsible for maintaining rental condition data. 

Trigger Event: New rental condition is created. 

.1.2.1 Main Success Scenario: User Creates Rental Condition Record 

gJStep 1: User selects a general condition to attach to a rental condition from the general conditions 


e (GEN_CNDS). The general condition must already exist on the GENCNDS table. 


h 

W 

1*1 


111 



Step 2: User provides the following information for the rental condition: 

• Start date of the rental condition (mandatory) 

• End date of the rental condition (optional) 

• Product instance code associated with rental condition (mandatory with a default of 'ALL') 

• Product type associated with rental condition (mandatory) 

• Distribution channel associated with a rental condition (mandatory) 

• Vehicle category to associate with rental condition (mandatory with a default of 'ACAR') 

• User area (UDA) ID rental condition is associated with (mandatory) 

• User Area Type (mandatory) 

• How to handle general condition. Sample values and there meanings are: 

A - Display during reservation and print on rental contract 

B - Display during reservation only 

D - Display during reservation and rental 

R - Display during rental only 

Y - Mandatory for reservation entry 

N - Not mandatory for reservation entry 
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These domain values are representative of the types currently supported by VRS. This list can be 
configured to reflect the Enterprise way of classifying display statuses currently in use. The domain 
for these values is located in the CG REF CODES table. 


2 J 

m 


IB? 

H- 

m 

?! 

Is?? 

it 5 


CI 


Column Description Column Name 

Data TvDe 

Rental Condition ID 

RCNJD 

Number (8) 

Display Status 

DSP_STAT 

Varchar2(l) 

General Condition ID* 

GCD__CNDJD 

Number(6) 

Start Date 

STRT DT 

Date 

UDA Area ID* 

UDA AREA ID 

Varchar2(10) 

UDA Area Type 

UDA ATY AREA TYP 

Varchar2(10) 

Vehicle Car Class 

VCA CAT CD 

Varchar2(8) 

Vehicle Car Class Suffix 

CAR CLS SUFX CDE 

Varchar2(4) 

Product Type 

PRT PROD TYP CD 

Varchar2(2) 

Distribution Channel 

DIST CHNL CDE 

Varchar2(12) 

Product Instance Code* 

PRI PROD INST CD 

Varchar2(8) 

Version Number 

PRI VER NBR 

Number(3) 

Contract Condition ID* 

CCO_CNTRCTL CND ID 

Number(8) 

End Date 

END DT 

Date 

Product ID 

PROD ID 

Varchar2(4) 

Reservation End Date 

RESJENDJDT 

Date 

Reservation Start Date 

RES STRT DT 

Date 

Comment Line 1 

RNT CMT LN1 

Varchar2(75) 

Comment Line 2 

RNT CMT LN2 

Varchar2(75) 

Rental Description 

RNT DESC 

Varchar2(2000) 

Product Category 

RNT PROD CAT 

Varchar2(l) 


*UDA AREAJD is a Foreign Key from the USR DFND AREAS table 
*PRI_PROD_INST_CD is a foreign key from the PROD JNSTS table 
*CCO_CNTRCTL_CND_ID is a foreign key from the CNTRCTL CNDS table 
*GCN_CND_ID is a foreign key from the GENCNDS table 


**BOLDED fields denote attributes having business values for this iteration 


The user provides the following data to create a rental condition: 


General condition to create rental condition for: 655 

Rental condition Start Date: 07-01-2001 

Product Instance code to associate condition to: 'ALL 5 

Product Type to associate condition to: 'R'etail 

User area to associate condition for: 0109 

User Area type: ATY_BR 

How to handle condition: Y 

Car Class 'ACAR' 

Distribution Channel: WEB 
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The following row is created in the rental conditions table (RNT_CNDS): 


RCNJD 

DSP S 
TAT 

GCD C 
ND ID 

STRT_DT 

PRI PROD 
INST CD 

PRI PR 
OD TYP 

UDA AREA 
ID 

UDA_ATY 
AREA TYP 

CAR CLASS 

DIST_CHNL 

2001 

D 

620 

06/03/01 

AW57E 

( R' 

01 

ATY GRP 

ACAR 

ALL 

2002 

D 

645 

07/01/01 

ALL 

'R J 

0109 

ATY BR 

ACAR 

BRANCH 

2003 

B 

648 

07/08/01 

WESO 

*R' 

0111 

ATY BR 

ACAR 

ALL 

2004* 

Y 

655 

07/01/01 

ALL 

'R' 

0109 

ATY BR 

ACAR 

WEB 


2.1.2.2 User Modifies a Rental Condition 

The only modifications allowable for an existing rental condition are to comment Lines 1-2. These 
are free text fields and text can be added, modified or deleted. Each line can hold up to 75 
characters. 


2.1.2.3 User Deletes a Rental Condition 


Sj*A rental condition is not physically deleted, rather logically deleted. In order to logically delete a 


^tental condition, an end date is provided for the record. By providing an end date, the record is 


Considered no longer active, thus logically deleted. 

a" . 

^p.1.2.4 User Creates a Rental Condition for all Vehicle Categories 


St J 


J^In order to associate a rental condition for all vehicle categories, the user will provide a car class of 
ITfACAR*. This will associate a rental condition to all car classes. 


.1.2.5 User Creates a Rental Condition for all Product Instances 


In order to associate a rental condition for all product instances, the user will provide a product 
instance code of ' ALL'. This will associate a rental condition to all product instances. 
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2.2 Proposed Rate Rules VRS Implementation 

The proposed VRS solution involves: 

• Utilizing the existing VRS General Conditions structure 

• Introduce two new display statuses of 'Y' and 4 N' for the location rate rule association 
field "mandatory for reservation entry". 

• Introduce three new condition types, MILEAGE, MISCELLANEOUS, DEPOSIT. 
GUARANTEE is already defined as a condition type. 

• Combining all the similar rule codes per group/branch combination into one general 
condition. 


From the observation of the records for Group 01 and Branch 10, it appears that the location rate rule 
association has the same rule code for all car classes and rate plan code. If this is the case, for each 
^igroup/branch combination, one general condition could be created for each rule code. If the rule 
Cjeode does vary by car class, then a general condition can be created for each car class. 

rtjThe current VRS messaging system can not separate messages based on the rate plan codes of daily, 
pjweekly, monthly. Weekend is implemented as a separate product in VRS. The messages will be all 
Jjthe same for a product and location. 

iii 

2.2.1 ERAC Rate Rules to VRS General Conditions Scenario 1 
!*<NATRES is the data source for examples below) 

ill 

jjGiven the following ERAC Location Rate Rule Association: 


Group 
Code 

Branch 
Code 

Pre- 

Arranged 
Discount 

Car 
Class 

Rule Type 

Rule Code 

Eff.Date 

End Date 

Rate 
Plan 
Code 

Mandatory 
for 

Res. Entry 

01 

10 

G 

CCAR 

MILE 

M01003 

20010215 

20350215 

D 

Y 

01 

10 

G 

CCAR 

MILE 

M01003 

20010215 

20350215 

E 

Y 

01 

10 

G 

CCAR 

MILE 

M01003 

20010215 

20350215 

M 

Y 

01 

10 

G 

CCAR 

MILE 

M01003 

20010215 

20350215 

W 

Y 

01 

10 

G 

FCAR 

MILE 

M01003 

20010215 

20350215 

D 

Y 

01 

10 

G 

CCAR 

MISC 

Z01037 

20010215 

20350215 

W 

N 

01 

10 

G 

ECAR 

GUAR 

G01000 

20010215 

20350215 

E 

N 

01 

10 

G 

LCAR 

DPST 

D10002 

20010215 

20350215 

D 

Y 


Given the following ERAC Rate Rule Header: 


Rule Type 

Rule Code 

Rule Description 

DPST 

D10002 

$500/NO CANCEL FEE 

GUAR 

G01000 

GUARANTEED RATE 

MILE 

M01003 

BORDER STATES ONLY 

MISC 

Z01037 

PHL TRANS TAX 
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Given the following ERAC Rate Rule Detail for Mileage and Miscellaneous: 


Rule Tvn<> 

Pulp 

Code 

•KcCOru 
Sequence 

Kuie lext 

MILE 

MO 1003 

1 

MILEAGE IS UNLIMITED WHEN VEHICLE REMAINS 
IN THE 

MILE 

M01003 

2 

RENTING STATE OR BORDERING STATES. 
VEHICLES ARE NOT 

MILE 

MO 1003 

3 

ALLOWED OUTSIDE OF THESE STATES. 

MISC 

Z01037 

1 

THERE IS A $2.00 PER DAY TRANSPORTATION TAX 
CHARGED BY 

MISC 

Z01037 

2 

THE STATE OF PENNSYLVANIA. THIS IS A 
MANDATORY CHARGE 

MISC 

Z01037 

3 

FOR ALL RENTERS. 


^Given the following ERAC Rate Rule Detail for Guarantee: 

155 #. 


s Iff 

iY 
Si 

n 

Rule Type 

Rule 
Code 

Record 
Sequence 

Guar 
Days 

Guar 
Begin 
Date 

Guar 

End 

Date 

Guarantee Text 

GUAR 

G01000 

1 

365 

0 

0 

GUARANTEE WITH 
RESERVATION 


ill 

flfGiven the following ERAC Rate Rule Detail for Deposit: 

JJ .5 . 


3 Rule 
I Type 

Rule 
Code 

Record 
Sequence 

Deposit 
Amount 

Currency 
Code 

Dep 
Days 

Dep 

Begin 

Date 

Dep End 
Date 

Deposit Text 

DPST 

D01001 

1 

50.00 

USD2 

0 

0 

0 

$50 DEPOSIT W/ 2 
WEEK CANCEL 

DPST 

D01027 

1 

200.00 

USD2 

0 

19960725 

99999999 

$200 DEPOSIT WITH 
72 HR CANCEL 
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2.2.2 VRS General Conditions Equivalent 

Using the above tables for rule type MILE and rule code MO 1003, the VRS general conditions 
equivalent is condition type MILEAGE. The VRS general conditions equivalents for rule type MISC 
and rule code Z01037 is condition type MISCELLANEOUS. The same relationship follows for rule 
type DPST and GUAR. 

Note: These are guidelines for data setup, not rules for conversion. 


The following records will be added to the general conditions table (GEN_CNDS): 


Condition 
ID 

Condition 
Type 

Condition Line 1 

Condition Line 2 

Condition Line 3 

320 

MILEAG 
E 

MILEAGE IS UNLIMITED 
WHEN VEHICLE 
REMAINS IN THE 

RENTING STATE OR 
BORDERING STATES. 
VEHICLES ARE NOT 

ALLOWED OUTSIDE 
OF THESE STATES. 

331 

MISCELL 
ANEOUS 

THERE IS A $2.00 PER 
DAY TRANSPORTATION 
TAX CHARGED BY 

THE STATE OF 
PENNSYLVANIA. THIS IS 
A MANDATORY CHARGE 

FOR ALL RENTERS. 

332 

GUARAN 
TEE 

GUARANTEE WITH 
RESERVATION 



333 

DEPOSIT 

$50 DEPOSIT W/ 2 WEEK 
CANCEL 




W the Rule Description in the Rate Rule Header file is needed, it will be put in condition linel and 
j^the rate rule text will be shifted to condition line x where x is the record sequence number plus 1. 

338 S 
III 

fljThe following records are created in the rental conditions table (RNT_CNDS): 


RCNID 

DSP 
STAT 

GCD 
CND 
ID 

STRTDT 

END DT 

PROD INST 

PRIJPRO 
DJTYP 

AREA ID 

AREA TYP 

CAR 
CLASS 

CAR 
SUFX 

DIST 
CHNL 

3001 

Y 

320 

20010215 

20350215 

RTLM1 

R 

0110 

ATY BR 

ACAR 

** 

WEB 

3002 

N 

331 

20010215 

20350215 

RTLM1 

R 

0110 

ATY BR 

AGAR 

** 

ALL 

3003 

N 

332 

20010215 

20350215 

RTLM1 

R 

0110 

ATY BR 

ECAR 

** 

ALL 

3004 

Y 

333 

20010215 

20350215 

RTLM1 

R 

0110 

ATY BR 

LCAR 

** 

GDS 
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In VRS, the General Conditions Engine provides valid messages for a rental dependent on the 
product type, product instance code, date of rental, distribution channel and location of the rental. All 
valid messages will be returned to the calling program. As with other sub-engines, the General 
Conditions Engine will traverse the rate hierarchy levels to determine the lowest level where a rental 
condition is defined for a product type, starting with the lowest level BRANCH. When the messages 
are found at a level in the hierarchy, the traversal of the rate hierarchy is stopped. 

The General Condition Engine is a tuxedo service that is called when information related to general 
I., conditions is required. Certain parameters must be sent to the engine for it to properly return the 
^correct information. Up to 25 rental conditions can be returned from a call. 

2... * 

1113.1.1 Inputs 

in 

C 1VRS currently uses the first field of an input buffer (conengtv001_version) to validate if a caller and 
*fthe service are using the same version of input and output buffers. Different versions will result in 
fhhe service call being terminated and an error message being returned to the caller. 

If 

rf jThe check out branch, check out time stamp, distribution channel, product instance and product type 
|||are the only mandatory fields required to correctly return general conditions for a retail product. 
fjlFailure to provide these fields to the General Conditions Engine will result in the call being 
G Jterminated and an error message being returned to the caller. 
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General Conditions Engine Input Parameters -Version : 01M~eoriL : :^^>V^V\vv4' XTecBitidd;- ^fowce df, \; 
'• -Input Parameter Ataes" ^^S35a^^Xs^»^ ? X - >5 ^ l ' 7>y*? Sfcirl Bate 







• - — ■ 








cont id 

Contract ID 

FN MEN CONT ID 

Optional 

lon S ... 

4 

Client App 

cntrctl end id 

Contractuai Condition 3D 

FN MEN CNTRCTL CND ID 

Optional 

long 

4 

Client App 

cntrctl end null 

Contractual Condition Null 

FN MEN CNTRCTL CND NULL 

Optional 

long 

4 

Client App 

best rate ind 

Best Rate Indicator 

FN MEN BEST RATE USED 

Optional 

Char 

3 

Rate Engine 

Prod usg status 

Product Usage Status 

FN MEN PROD USG STATUS 

Optional 

Char 

3 

Rate Engine 


3.1.2 Outputs 

The General Conditions Engine returns the list of general conditions and associated attributes for the 
specified rental. The output structure for this service and the associated details for the structure 
elements are described below. The outputs from the General Conditions Engine are returned in a 
prioritized order based on the following order of precedence: child customer, root customer, product 
instance, all distribution channels, specific distribution channels, specific car class and 'AGAR'. 

pjThe engine error field captures the error number associated with the service call Any value other 
f!|than zero indicates that an error occurred and the results of the output buffer are undefined. 

ml 

IliRecord count (rec_count) indicates the number of conditions returned from this call. The remaining 
Ofields in the output structure after this field have multiple occurrences as indicated by the record 
f - {count (rec_count). The General Conditions engine can return up to 25 records per call. 

j- j, The structure elements indicated as C_<element name> are the count member as defined by the 
njTuxedo FML buffer specifications. There is a count field in the structure for each of the fields 
fljhaving multiple occurrences in the output buffer. 


fii 


iThe general condition ID (endjd) field contains the ID of the general condition selected from the 
^General Conditions table (GEN_CNDS), 

The display status (dsp_status) field contains the one character identifier used to determine how the 
condition is to be displayed. 

The condition line 1, condition line 2, condition line 3 and condition line 4 fields (cndjnl, cndjn2, 
cndjn3, cndjn4) are used to store the text associated with the general condition. Although a 
general condition can have up to 30 lines of text associated with it, the General Conditions Engine 
only returns the first four lines. The remaining lines of text can be retrieved using the condition ID 
as a key to retrieve the lines from the general conditions (GEN_CNDS) table. Current VRS 
functionality does not accommodate this process and this feature would require the development of a 
new maintenance screen and service. 
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The comment line 1 and comment line 2 fields (cmtjbil, cmt_ln2) are used to store the text 
associated with the rental condition. 





Oa^w/i Parameter ^ 


/. JCtCt' vfCRftL 

n 7 


Error jno 

Server error Code or 0 

FN_CEN_ERR_STATUS 

Mandatory 

long 



err_text 

Server Enor Text 

FN_CEN_ERR_MES SAGE 

Optional 

char 

81 


rec_count 

Number of records returned 

FN_CEN_REC_COUNT 

Mandatory 

Long 



end jd 

Up to 25 condition ID's 

FN_CEN_CNDJD 

Optional 

Long 

[25] 

GENCNDS 

dsp_status 

Up to 25 display statuses. 

FN_CEN_DSP_STATUS 

Optional 

Char 

[25][2] 

RNT_CNDS 

cndjnl 

General Condition Line 1 

FN_CEN_CND_LN 1 

Optional 

Char 

[25j[76] 

ueN_LJNJLo 

cndjn2 

General Condition Line 2 

FN_CEN_CND_LN2 

Optional 

Char 

[25][76] 

GEN_CNDS 

cndjn3 

General Condition Line 3 

FN_CEN_CND_LN3 

Optional 

Char 

[25][76J 

GEN_CNDS 

cndjn4 

General Condition Line 4 

FN_CEN_CND_LN4 

Optional 

Char 

[25][76] 

GEN_CNDS 

cmtjnl 

Comment Line 1 

FN_CEN_CMTJLN 1 

Optional 

Char 

[25][76] 

RNT_CNDS 

cmtjn2 

Comment Line 2 

FNJ3EN_CMT_LN2 

Optional 

Char 

[25][76] 

RNT_CNDS 

addJpsjwl Jig 

(a J 

H 

Additional lines available flag which 
indicates more than 4 General 
Condition Lines are available to be 
displayed 

FN_CEN_ADDJLNS_AVL 

Optional 

Char 

[25][1] 



S 3 


I 

013.1.3 Detailed Process Flow 

r! 

; % |The Rental Conditions (RNT_CNDS) table combined with the General Conditions (GEN_CNDS) 
w table contains the information needed to return valid rental conditions for the product type, check out 
1^, date, and check out location. A rental condition can be defined for a product type at any given level 
fyof the rates hierarchy. The General Conditions Engine can receive as input an area list containing the 
pjfuser defined areas (UDAs) a branch belongs to. If the area list is not provided by the calling service, 
fitthe General Conditions Engine builds the area list by querying the Station UD A (STAJUDA) table. 

l**This list, having been passed or built, combined with the distribution channel, product type, vehicle 
code and check out time stamp, is used to search the rental conditions (RNT_CNDS) table for valid 
conditions. The rates hierarchy list is traversed until one or more valid entries are found. Once a 
valid entry is found, the traversing of the rates hierarchy is terminated. All valid rental conditions 
defined at this level are captured by the Engine and returned to the calling program. 

The current implementation returns the Superset of messages defined for the combination of Specific 
Product + standard rate type (product type) + Specific Car Class + ACAR for the lowest rate 
hierarchy level. For Iteration 3 the returned set of records will be filtered down to : 

From the lowest hierarchy level for a Specific Distribution Channel in this order: 

1. Specific Product + Specific Car Class (Example RTLM1 + ECAR). 

2. Specific Product -f ACAR (Example RTLM1 + ACAR). 

3. Specific Product type + Specific Car Class (R + ECAR). 

4. Specific Product type + ACAR (R + ACAR). 
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jjHSs: 

h 

M 

SB 3 


H 

hi 


Rate Engine 


General 
Conditions 
Main 


Start 


Input Structure 


Area List 
Product Instance 
Code 

Distribution 
Channel 
Check Out Date 


Output Structure 


Up to 25 

Record Counts 
Number of Condition IDs 
Condition ID 

Number of Display statuses 

Display Status 

Number of Condition Line 1 

Condition Line 1 

Number of Condition Line 2 

Condition Line 2 

Number of Condition Line 3 

Condition Line 3 

Number of Condition Line 4 

Condition Line A 

Number of Comment Line 1 

Comment Line 1 

Number of Comment Line 2 

Comment Line 2 


Return 


Search 
Rate 
Hierarchy 
based on 
Location 


Base search on location, 
check out date, product 
instance and vehicle 
category. If no conditions for 
specified vehicle category, 
search for 'ACAR' or NULL 
category 


Search for 
Conditions 


Create 
Output List 


Retrieve info 
from STAJJDA 
table 


i 


i 


Return Search 
j Criteria 


Get Applicable 
Conditions 


Return List of Conditions 


Traverse hierarchy, from lowest 
(Branch) to highest (Company), 
to find match. Once match is 
found it will stop at that level 


Move list to the output structure 



Move remaining 
items to output 
structure 


3.1.3.1 Scenarios 

Different scenarios are used to illustrate the variation in the output list of conditions types based on 
the inputs as indicated below. 


For the purpose of this illustration we will assume that the General Conditions table in VRS is 
populated as indicated below. 


Cnd Id 

Typ 

Cnd Lnl 

Cnd Ln2 

620 

ELIGIBIL 
ITY 

To be eligible for this rate, renter must be resident of the US 


631 

AGE 

Renter must be 21 years or older to rent. Young renter fee does 
not apply. 


645 

SERVICE 

If customer waits more than 45 minutes for a vehicle 

Apply a $25 courtesy 
adjustment 
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v^nu la 

T yp 

Cnd Lnl 

Cnd Ln2 ] 

648 

AGE 

Renters must be 25 years or older to rent 



RJbrbRJb 
NCE 

Do not offer vehicle upgrades 



KbrbKh 

MAJOR CCARD PREFERRED 


NCE 


jDj 

isJir c,ivfc, 

RiiAlL RENTER. MUST VERIFY HOME ADDRESS 





A/f TT A n 

MILEAGE IS UNLIMITED WHEN VEHICLE REMAINS IN 

OR BORDERING 

E 

TUD D DXTTTXT/"* CTATP 

1 hLb KbJN iiJSKjrSlAlE 

STATES 

371 

MISCELL 

THERE IS A $2.00 PER DAY TRANSPORTATION TA Y 

lo A MAJN DA 1 UKY 

CHARGE 

ANEOUS 

CHARGED BY THE STATE OF PENNSYLVANIA. THIS 

375 

RETAIL 

RENTERS MUST BE 25 YEARS OR OLDER TO RENT 


378 

DEPOSIT 

$50 DEPOSIT W/2 WEEK CANCELLATION 


385 

MISCELL 
ANEOUS 

COUPONS HAVE SPECIAL REQUIREMENTS - MUST 

MENTIONS THEY 

CALL BRANCH FOR RATES/RULES IF CUSTOMER 

HAVE A COUPON 


Li For the purpose of the illustration, we will assume that the Rental Conditions table in VRS is 


hpopulated as indicated below. 


JRCNJD 

1' 

DSP 

STAT 

GCD CND 
ID 

strtj)t 

PRI PROD 
_INST_CD 

PROD_ 
TYP 

UDA 
AREA 
ID 

UDA ATY 
AREAJTYP 

CAR CLASS 

DIST_CHNL 

1 2001 

D 

620 

06/03/01 

ALL 

R 

01 

ATY GRP 

ACAR 

ALL 

1 2002 

D 

645 

07/01/01 

ALL 

R 

0109 

ATY BR 

ACAR 

BRANCH 

\ 2003 

B 

648 

07/08/01 

ALL 

R 

0111 

ATY BR 

ACAR 

ALL 

" 2004 

D 

655 

07/01/01 

ALL 

R 

0109 

ATY BR 

ACAR 

BRANCH 

3008 

D 

350 

06/03/01 

RTLM1 

R 

0109 

ATY BR 

ACAR 

BRANCH 

3009 

D 

355 

07/01/01 

ALL 

R 

0109 

ATY BR 

ECAR 

BRANCH 

1 3011 

N 

370 

06/03/01 

RTLM1 

R 

0109 

ATY BR 

ACAR 

GDS 

j 3012 

D 

375 

07/01/01 

RTLM1 

R 

0101 

ATY BR 

ACAR 

BRANCH 

: 3013 

Y 

371 

07/01/01 

RTLM1 

R 

0101 

ATY BR 

ACAR 

WEB 

* 3014 

Y 

378 

07/08/01 

RTLM1 

R 

0101 

ATY BR 

ACAR 

WEB 

1 3015 

N 

385 

07/01/01 

ALL 

R 

0109 

ATY BR 

ECAR 

GDS 


i* Bolded row represents new entry for iteration 3 
3.1.3.1.1 Scenario 1 - Rental is being made for the location 0109 

Input Parameters: 


Branch 
Pickup Date 
Product Type 
Product Instance 
Distribution Channel BRANCH 
Car Class SCAR 


0109 

200107011000 
R 

RTLM2 


For the above scenario, the STAJUDA table is first searched to build an area list comprised of areas 
where the branch ID 0109 exists. Once this is completed, the rental conditions (RNT_CNDS) table 
is searched for valid conditions based on the area list, the distribution channel, product type, product 
instance code, car class and the check out date of the rental. Based on the sample data above, the 
following records would be returned by the General Conditions Engine. 
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The list of returned records: 


Type 

Name 

Records Returned fl] | Records Returned [21 

Long 

Engine error 

0 ' " 

Char 

err text 


Long 

Rec count 

2 

Long 

end id 

645 

655 

Char 

dsp status 

D 

D 

^nar 

cnd__lnl 

If customer waits more than 45 minutes for 
a vehicle 

Do not offer vehicle upgrades 

Char 

end ln2 

Apply a $25 courtesy adjustment 


Char 

end ln3 



Char 

end ln4 



Char 

cmt lnl 



Char 

cmt ln2 




■c 


j3.1.3.L2 Scenario 2 - Rental is being made for the location 0108 

Cllnput Parameters: 


y 


IBranch 
Pickup Date 
^Product Type 
^Product Instance Code 
^Distribution Channel 
Car Class 


0108 

200107061000 
R 

RTLM2 

BRANCH 

SCAR 


la this scenario, there are no records on the rental conditions table defined at the branch level for 
branch ID 0108. The engine then continues searching for a valid entry at the next level of the 
hierarchy until a valid entry is found. In this example, the engine selects the following record which 
is valid for all branches in group 01: 


Type 

Name 

Records returned fl] 

Long 

Engine error 

0 

Char 

Err text 


Long 

Rec count 

1 

Long 

Cnd id 

620 

Char 

Dsp status[25] 

D 

Char 

Cnd lnl 

To be eligible for this rate, renter must be resident of the US 

Char 

Cnd ln2 


Char 

Cnd ln3 


Char 

end ln4 


Char 

cmt lnl 


Char 

cmt ln2 
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3.1.3.1.3 Scenario 3 - Rental is being made for the location 01 ftt 

Input Parameters: 

Branch 0101 

Pickup Date 2001 0701 1 000 

Product Type R 

Product Instance RTLM1 

Distribution Channel WEB 

Car Class FCAR 


For the above scenario, the STAJJDA table is first searched to build an area list comprised of areas 
where the branch ID 0101 exists. Once this is completed, the rental conditions (RNT_CNDS) table 
is searched for valid conditions based on the area list, the distribution channel, product type, product 
instance code, car class and the check out date of the rental. Based on the sample data above, the 
H following records would be returned by the General conditions Engine. 

PI 

|? The list of returned records: 

ill 


Type 

Name 

Records Returned [11 Records Returned [21 

Long 

engine error 

0 

Char 

err text 


Long 

rec count 

2 

Long 

end id 

371 

378 

Char 

dsp status 

Y 

Y 

Char 

cnd_lnl 

THERE IS A $2.00 PER DAY 
TRANSPORTATION TAX CHARGED BY 
THE STATE OF PENNSYLVANIA. THIS 

$50 DEPOSIT W/2 WEEK 
CANCELLATION 

Char 

end ln2 

IS A MANDATORY CHARGE 


Char 

end ln3 



Char 

end ln4 



Char 

cmt lnl 



Char 

cmt ln2 
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3.1.3.1.4 Scenario 4 - Rental is being made for the location 0109 

Input Parameters: 

Branch 0109 

Pickup Date 200107061000 

Product Type R 

Product Instance Code RTLM1 

Distribution Channel GDS 

Car Class LCAR 


In this scenario, the engine selects the following record which is valid for all branches with 
distribution channel GDS: 


Type 

Name 

Records returned fl] 

i I Long 

engine error 

0 

;fChar 

err text 


j}Long_ 

rec count 

1 

•;Long 

end id 

370 

•"Char 

dsp status 

N 

fChar 

£ 

cndjnl 

MILEAGE IS UNLIMITED WHEN VEHICLE REMAINS IN THE RENTING 
STATE 

IChar 

end ln2 

OR BORDERING STATES 

Char 

end ln3 


*Char 

end ln4 


J Char 

cmt Inl 


IChar 

cmt ln2 



3.1.3.1,5 Scenario 5 - Rental is being made for the location 0109 

Using the same scenario as above except changing the car class from LCAR to EC AR. 
Input Parameters: 


Branch 
Pickup Date 
Product Type 
Product Instance Code 
Distribution Channel 
Car Class 


0109 

200107061000 
R 

RTLM1 

GDS 

ECAR 


In this scenario, the engine selects the following record which is valid for all branches with 
distribution channel GDS: 


Type 

Name 

Records Returned fl| 

Records Returned [2] 

Long 

engine error 

0 


Char 

err text 



Long 

rec count 

2 




rent-a-car 


ECARS v2.0 - Accurate Out the Door Pricing 
Detailed Design Specification 


perotsystems* 


Type 

Name 

Records Returned fl| 

Records Returned [2] 

Lone 

cnrl \c\ 

o /u 

385 

Char 

Hcr> ctatnc 

UOU ijUIIUj 

N 

IN 

N 

Char 

end 1n1 

iviix-riiAvjii io UJNJLIJVli I ndJ WrLbN 
VFRTPT F PFMATMC T\T Tilt? 

RENTING STATF 

COUPONS HAVE SPECIAL, 
REQUIREMENTS - MUST CALL 
BRANCH FOR RATES/RULES IF 
CUSTOMER j 

Char 

end ln2 

OR BORDERING STATES 

MENTIONS THEY HAVE A COUPON 

Char 

end ln3 



Char 

end ln4 



Char 

cmt Inl 



Char 

cmt ln2 




3.1.3.1.6 Scenario 6 - Rental is being made for the location 0109 

Input Parameters: 


f* ^Branch 
"Pickup Date 


^p^roduct Type 


n 


Product Instance Code 
HCar Class 
^^Distribution Channel 


0109 

200107061000 
R 

RTLM2 

ECAR 

BRANCH 


« In this scenario, the engine selects the following record which is valid for all branches with 
^distribution channel BRANCH and Car Class of ECAR- 

111: 

jlfEven though records 645 and 655 are valid for the BRANCH distribution code they have a car class 
|x>f ACAR. Using the new selection criteria they would be eliminated by the availability of record 355 
; B| which is an ECAR. 

'JS Si 


Type 

Name 

Records Returned [11 

Long 

engine error 

0 

Char 

err text 


Long 

rec count 

1 

Long 

end id 

355 

Char 

dsp status 

D 

Char 

cndjnl 

RETAIL RENTER. MUST 
VERIFY HOME ADDRESS 

Char 

end ln2 


Char 

end ln3 


Char 

end ln4 


Char 

cmt Inl 


Char 

cmt In2 
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3.1-3.1.7 Scenario 7 - Rental is being made for the location 0109 

If the above scenario is modified such that the product instance code is RTLM1, then 
Input Parameters: 


Branch 
Pickup Date 
Product Type 
Product Instance Code 
Car Class 

Distribution Channel 


0109 

200107061000 
R 

RTLM1 

ECAR 

BRANCH 


In this scenario, the engine selects the following record which is valid for all branches with 
distribution channel BRANCH and Car Class of ECAR and Product Instance of RTLM1 
f^Only record 350 will be returned as all others fail Product Instance, Car class and order criteria. 


ill 

Ui 
Si 

Type 

Name 

Records Returned 
[11 

Long 

Engine error 

0 

Char 

err text 


Li j 

Long 

Rec count 

1 

«■ 

5 . 

U : 

Long 

end id 

350 

Char 

dsp status 

D 

Char 

cnd_lnl 

MAJOR CCARD 
PREFERRED 

m 

w. 

Char 

end ln2 


Char 

end ln3 


Char 

end ln4 


Char 

cmt lnl 


Char 

cmt ln2 
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4.1 Risks 


4.2 Assumptions 


• If the rate rule text is the same for the NATRES rate plan code and car class, the message 
can be implemented as one general condition using ACAR as car class. 

• NATRES file structure currently allows rate rules to vary by rate plan (daily, weekly, 
monthly). In VRS, messages can not vary at this level. 

• NATRES rate rule details, such as DPST, have additional fields that will not be supported 
by VRS messaging structure. 

• The guarantee days will be implemented at the product instance using the guaranteed days 
S| ■ .- field. 

p| • Messages are defined only for the highest level of distribution channel hierarchy. 
Ill • The General Conditions Engine will return all messages meeting the following search 
0 conditions: 

■*J 1 . Message must exist for the given UDA hierarchy and 

W- 2. Message defined for a specific product type and 

* , 3 . Message defined for a specific car class or ACAR and 

55 1 4. Message defined for a specific product instance code or ALL and 

ill 5. Message defined for a specific distribution channel or ALL. 

m ■ 
p 

f " 43 Issues 

N/A 
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5.1 Data Model 


RNT CNDS 



CI 

Ml 
111 
Cl 


■1st 
Sir J? 


5 


#RCN_ID 
#DSP_STAT 
#*GCD_CNDJD 
#*STRT_DT 

* CCO_CNTRCTL_CND JD 
END_DT 

* PRl_PROD JNST_CD 

* PRI_VER_NBR 
PRODJD 
RES_END_DT 
RESISTRT_DT 
RNT_CMT_LN1 
RNT_CMT_LN2 
RNTJDESC 

* RNT_PROD_CAT 

* UDA_AREA_ID 

* UDA_ATY_AREA_TYP 

* VCA_CAT_CD 

* CAR_CLS^SUFX_CDE 
PRTJPROD_TYP_CD 
DIST CHNL CDE 


NUMBER(8) 
VARCHAR2(1) 
NUMBER(6) 
DATE 

NUMBER(8) 
DATE 

VARCHAR2(8) 
NUMBER(3) 

VARCHAR2(4) 

DATE 

DATE 

VARCHAR2(75) 

VARCHAR2(75) 

VARCHAR2(2000) 

VARCHAR2(l) 

VARCHAR2(10) 

VARCHAR2(10) 

VARCHAR2(8) 

VARCHAR2(4) 

VARCHAR2(2) 

VARCHAR2(12) 


STA UP A 
ATY_AREA_TYP 
AREAJD 
AREA DESC 



PROD INSTS 


PROD_INST_CD 
VER NBR 


GEN CNDS 

#CND_ID ISfUMBER(6) 
#TYP VARCHAR2(20) 
#CND_LN1 VARCHAR2(75) 

CNDJLN2VARCHAR2(75) 
CND^LN3-30 VARCHAR2(75) 
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5.2 Use Case Diagram 


a.-, a 


ft- 

V| 
lit 


J. If- 

■PI 

"4* % 


O 



Acton 


{Each general conditions is of specific type (domain).} 


System 


/laintain Gener- 
Conditions 


{Associate RentaiCondition to General Condition} 


aintainRentalConditN 
ionByConditionld 


-End9 


«ext€ nds» 



-End10 


O 


A 


Actor2 


^RntConditionForSpecN 
IficVehicleCatg 
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rPRODJD 
PROD..DESC 
PRT PROD TYP CD 
, 

TJ 
X 

S 

k 


>0— PRDJDF- 


Prod Tvos 

#*PROD_TYP_CD 

PROD_TYP_DESC 
Iq BILL CYCL 


r 


Prod insts 


#*PROD INST.CD 
PRD PRODJD 
CRY ARIMP_CRY_CD 
PRODJNSTDESC 
CREATE JJSERJD 
CREATEJXT 
o CUR_CURR_CD 
o VER_NBR 

o AIRLINE TICKET REQD IND 
o AUTH STAT 
o AUTCf RECMPTJRT 
o BEST_RT_FLG 
o COMPANYJSD 
o COM_FLG 
o CO_STRT DT 
o FREE_VHCL COLL 
o FREE_VHCL DLVR 
o FUEL INCL_FLG 
o GTEE RT IND 
o GUAR_DAYS NBR 
o MAX COM_RT 

ONE_WAY_ONLY 
O PREF_CHANJND 
o RES_STRT DT 
o RT BASE_UNITCD 
o SEC RATE IND 

oauthLdt 

o AUTH USR 
o CO END_DT 
o CPL PLAN J D 
OCRS STAT 
o DBG BNDJD 
o DSCNT_FLG 
o EXR TYP CD 
o FF TVL FLG 
o MAX DSCNT_RT 

o minj?nt_day_forj>om 

o M!N__RNT DAY_FORJNT 

o PRI_RANKJND 

0 PROD_USG_STAT 

o RES_CHNG_FLG 

O RES END_DT 

o SALE TX INCL FLG 

o SELF_SVC IND 

o UNBLD FUEL_RENT_AMT 

o SCHGJNCL_FLG 

0 LASTJJPDT USERJD 

o LAST_UPDT_DT 

o IPC CPL.PLANJD 


PROD_TYPS_FK 

f Distribution Channel Rate AdP \ 
#*DCRA SEQJvlBR 
UDA AREA ID 
UDA ATY_AREA_TYP 
PRT PROD TYP CD 
EFF STRT DT 
EFF END DT 
ADJJTYP.CD 
DLY_ADJ 
oWKLY ADJ 
p MTLY ADJ 


-PRODJ\VLS_FK- 


-RHJPRODJNSTS.FK* 


Rates Header ^ 

#*RTH UMQ ID 

* CREATEJ3T 

* CREATE_OPERJD 

* CUR CUR.CD 

* EFFC END DT 

* EFFC STARTJDT 

* PRC PRODJNSTCD 

* PROD ID 

* rtj3asejjnit_cd 

* max dscnt^rt 

* sales tx inclflg 

* uoa_areajd 

* schgjncl flg 

* uda aty area typ 

* prim ratejnd 

* rat£headerj>e$c 

* PRT PRODJTYPjCD 

* FUEL INCL FLG 
*PRT_BILLJCYCL 

o AIRLINE TICKET REQDJND 

o LOCAL ONEWAY IND 

o BEST RTFLG 

o RATE JTYPE JND 

o SEC RATE IND 

OVER NBR 

o DIFF_APPLY FLG 

0 DSC NT FLG 

oEXR TYP_CD 

o LST CHG DT 

oLST.CHG USR 

o ONE WAY_ONLY 

0 PRIJRANK IND 

oPRODJJSG STAT 

o RESJEND DT 

0 SPEC CTYJ=LG 

o STN STN ID 

oBLD PROD FLG 

o DISC TYPE IND 

A RECJND 


DCRAJJDA_FK 


*-RH__UDA_FK~ 


Prod Avis, 
r PROD_AVLJD 
AVL FOR 
EFFC END DT 
EFFC START_DT 
INCL STAT 
PROD AVL TYP 
PRC PRODJNST^CD 
o DiSfCHANL JD 
o CCO_CNTRCTL_CND ID 
o CRY_ARIMP_CRY_CD 
o PRC VER_NBR 
o STA_STNJD 
o UDA AREA ID 
o UDA_ATY AREAJfYP 


AVLS _UDA_FK 


Usr Dfnd Areas 

#*ATY AREA.TYP 
rAREAJD 
* AREA DESC 
o INV CNTLJND 


3 


Sta Uda 

#*AREAJD2 
#*ATY AREA_TYP2 
#*STN ID1 
#*EFF_START DT 
o EFF_END_D? 


Rate Header and Rate Detail Relationship 


f Rates Header 

#*RTH UN1QJD 

* PROD TYP_CD 

* PRC.PRODJNST CD 
PRODJD 
UDA_AREA_ID 

* UDA_ATY_AREA_TYP 

* EFFC_END_DT 

* EFFC_START_DT 

* RT_BASEJJNITCD 

* RATEJiEADERJ>ESC 

* PRIM_RATEJND 

* CUR.CUR CD 

* MAX_DSCNT_RT 

* SCHGJNCL.FLG 

* SALESJTXJNCL^FLG 

* FUEL INCL_FLG 
CREATE_DT 

* CREATE_OPERJD 

o AIRLINE_TJCKET_REQDJND 

o LOCAL_ONEWAY IND " 

o BEST RT_FLG 

0 RATEJTYPEJND 

o SEC_RATE_IND 

o VERJMBR 

0 DIFF APPLY^FLG 

o DSCNTJLG 

o EXR TYP CD 

o LST_CHG_DT 

o LST_CHGJJSR 

o ONE-WAY ONLY 

OPRI RANK IND 

o PRODJJSGLSTAT 

o RES_ENDj5T 

o SPEC_CTY_FLG 

o STN_STNJD 

o BLD_PROD_FLG 

o RECJND 


-Owns- 


Rate Details 

#* RTDJD 

* RH_RTH_UNIQJD 

* RTD TYPE 

* VCTCAT.CD 

* CAR CLASS_SFX 

* RES STRTJDT 
RES END DT 

* CO_STRT_DT 
CO_END_DT 

O HR_AMT 
oHR WIL_NBR 

* DLY_AMT 

o DLYJVHL_NBR 

oWKAMT 

OWK MIL_NBR 

o WITH AMT 

o MTH_MIL_NBR 

o MTH FACTOR_NBR 

o XTRAJDAYj\MT 

o XTRA_DY MILNBR 

o XTRAJ-IR_AMT 

o XTRAJ-IRJVIIL NBR 

o EXCESS JWlLjiMT 

* CREATE_DT 

* CREAT OPERJD 

* AUTH_FLG 
o AUTH_DT 
OAUTH USRJD 
o UPDT_DT 

O UPDT OPERJD 
o BASEJDAYS 
o BASE_RT 
o DLY_FRI AMT 
o DLY_MON_AMT 
o DLY_SAT_AMT 
0 DLY_SUN_AMT 
o DLYJTHU AMT 
o DLYJTUE_AMT 
o DLYJA/ED_AMT 
o GRS_DY_AMT 
oGRS HR_AMT 
o GRS_WK_AR/1T 
o HR_FRI_AMT 
o HR MONAMT 
o HR_SAT_AMT 
o HR_SUN_AMT 
o HR_THU_AMT 
o HR TUE_AMT 
o HR WED AMT 
o PLUS1 AMT 
o PLUS2 AMT 
o PLUS3 AMT 
0 PLUS4_AMT 
O PLUS5 AMT 
0 PLUS6_AMT 
o RTE_DISC_PCT 
Vg HfSTORY FL G 


Rate Header, Rate Header Qual Association, Rate Qual, and Rate Detail Usages 

Relationships 


f Rate Header Qual Assn 

#*RHQA UNIQ ID 

* RH RTH UN1QJD 

* RDB DRTNJ3ND_CD 

* RES_END_DT 
*RES START DT 

* EFFC ENDDT 

* EFFC START_DT 

* CREATE DT 

* CREATE_OPER 
o UPDTJDT 

o UPDT OPER 


-Assoc Quai- 


Owns 


Rates Header > 

#*RTH_UNIQJD 

* PROD TYP CD 

* PRC_PRODJNST_CD 

* PRODJD 
UDAJVREAJD 

* UDAJVTY AREAJTYP 

* EFFC ENDJ)T 

* EFFC 3TARTDT 

* RT BASE_UNIT_CD 

* RATEJ-/EADERJ3ESC 
PRIM_RA TEJND 

* CUR^CUR _CD 

* MAXJ)SCNT_RT 

* SCHG_INCL_FLG 
SALES_TXJNCLJ=LG 
FUEL TNCL FLG 
CREATEJ)? 
CREATEJ3PERJD 

o AIRLINE TICKETREQDJND 
o LOCAL ONEWAYJND 
o BEST RT_FLG 
0 RATE TYPE 1ND 

o secJratejnd 

OVER NBR 
o DIFF_APPLY_FLG 
o DSCNT FLG 
o EXR_TYP_CD 
o LST_CHG_DT 
oLST_CHGJJSR 
o ONE WAY ONLY 
o PRHRANKJND 
o PROD USG.STAT 
o RES_END_DT 
o SPECCTY^FLG 
0 STN_STNJD 
o BLD_PROD_FLG 
o REC IND 


-Owns- 


-Uses Rates Owned By- 


RNTDRTN BNDS > 

#* DRTN_BND_CD 
CHG UNIT_CD 
DRTN BNDJDESC 
MINJRNTJ5RTN 
MSN RNTN_DRTNJJN1T_CD 
MAX RNT_DRTN 
MAX_RNTN_DRTN_UNIT CD 
O CLBY 

o CLDAY OF_WK 

o CO END DAY 

o CO FROM 

O CO STRT DAY 

o CO UPTO 

o CREATE USERJD 

o CREATEJ3T 

o EXCL DAYS_STR 

o INCL DAYS_STR 

o REQ OVNT_STRJ)ESC 

0 CHECKINJATESTJDT 

0 EXCL DAYSJWASK 

0 !NCL_DAYS_WIASK 

o MAX RNTJDRTN_EXTRA 

0 MIN CHG FRLNBR 

0 MIN CHG_MON_NBR 

0 MIN CHG_SAT_NBR 

o M1N CHG SUN_NBR 

o MtN CHG_THU_NBR 

o MIN CHG_TUE_NBR 

0 MIN CHG_WED_NBR 

o RDB DRTN BND_CD_EXT 

o REQ_OVNT_MASKJ\IBR 

0 ADV_BKG FLG 

o PREPAY CNDS_FLG 


Rate Detail Usages 


J 


^#*RH RTH UNIQJD 

* RH RTH UNIQJDJREF 

* REDSTART DT 

* RES_END_DT 

* CO START DT 

* CO END DT 

#*cr!atejdt 

* create oper 

o UPDATE_DT 
o UPDATE_OPER 
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1.1 Overview 


This document provides detailed design specifications of the processes required to load and maintain 
third party rental and rental transit tax rates. In addition to the processes required to load and 
maintain tax rates, a one-time process will be developed to create the database entries required to 
represent the appropriate jurisdictions and jurisdiction hierarchies with which corresponding tax rates 
will be associated. These processes are intended to be used for loading and mamtaining the rates 
supplied by a third party vendor, Research Institute of America (RIA). It is anticipated that 
s additional loading and maintenance will be required for rates other than those supplied by RIA and 
Jliyhenever Enterprise chooses to modify the rates or geographic divisions as supplied by RIA. 

till .2 Dependencies 

CJ 

irJThe processes described in this document are dependent on the use of the current file formats as 
described in the RIA InSource Sales & Use Tax Rate Update Subscription Service Release Notes 
„ dated March 19,2001. 

H 

jjjl.3 Data Conversion 

:sii 

plThe initial loading of rental and rental transit tax rates into the database as well as generation of the 
T database entries required to represent the tax jurisdictions and related hierarchies wall be 
accomplished through conversion of RIA rate data in conjunction with existing Enterprise branch 
data. Initial conversion will require a complete RIA rate file. The initial conversion will load the 
complete RIA tax data into the database, generate the appropriate tax areas and area hierarchies, and 
generate the related tax rates. Subsequent executions will load the monthly RIA update data into the 
database and update the tax rates, but will not perform any area or hierarchy maintenance. Any 
maintenance required to keep the area and hierarchy definitions synchronized with the RIA data will 
be handled manually. 

It is anticipated that a significant amount of manual intervention will be required to comprehensively 
maintain all applicable tax rates. 

1.4 Impact Analysis 

This is a data conversion process only and there are no impacts to any functional areas. 


Last Save Date: 10/1 7/200 1 2:03 PM 


Page 4 of 39 


Sales Tax Conversion Design 



2.1 Overview 


Three batch processes will be developed to read the RIA tax rate file and Enterprise's branch 
information to create the database entries needed to store applicable rental and rental transit tax rates. 
The first process will read the RIA file and load the required rate information directly into a database 
table to facilitate further processing. A second process will read this rate information in conjunction 
with the branch data and ensure that the appropriate database structures (tax areas, tax area 
hierarchies, and other supporting information) are built to allow each branch to be associated with the 
correct rental and rental transit tax rates. The tax areas and area hierarchies will be created once 
during the initial conversion process. The third process will perform the initial loading of tax rates 
h ^and maintain them on an on-going basis, based on the rate data supplied by RIA. 

pOnly those rates applicable to an area in which Enterprise operates a branch will be loaded. In this 
fl jcontext, an area refers to the appropriate state, county, or city imposing the tax. During the initial 
0 ^conversion, sufficient information will be stored in the database to allow each branch to be 
Jjassociated with specific rates, based on the branch's geographic location. 

s>i 

^Individual rates will be loaded at the appropriate level in the geographic hierarchy of areas (also 
^called tax and surcharge user defined areas). For example, state rental and rental transit tax rates will 
p jbe stored at and associated with the state/province level. All local tax rates will be stored at and 
Rfassociated with the appropriate county or city level A county will be created in the hierarchy for 
|teach county in which Enterprise operates a branch. A city will be created in the hierarchy for each 
. KJcity, having a rental tax or rental transit tax rate greater than zero, in which Enterprise operates a 
^branch . Multiple local rates will be stored at the appropriate level where applicable. For example, if 

Colorado Springs assesses a 2. 1 % rental tax in addition to a 1% rental transit tax, both rates would be 

stored separately at the city level. 

A mechanism will be provided to designate specific states for which rates will not be loaded from the 
RIA file. For example, in Virginia, the tax rate applicable to motor vehicle rentals is 8%, regardless 
of the Virginia general tax rate of 3.5% or the local jurisdictions 9 rates. Therefore, the general tax 
rates in the RIA file would not be applicable to rental car transactions and, as such, Enterprise may 
not want to load them. In this case, rates applicable to Virginia localities should not be loaded from 
the RIA file. However, if local tax records are present for a given state in the RIA file, the 
appropriate tax areas and related hierarchies will be created down to a level (state, county, or city) 
specified for each state. Continuing the Virginia example, the applicable rate of 8% for Virginia 
transactions would be established outside of the RIA data conversion process. Numerous other states 
have similar considerations. Therefore, the states for which tax rates will be taken from the RIA file 
will be controllable. 
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The processes described in this document are designed to convert rates provided by RIA. It is 
anticipated that significant manual maintenance and verification will be required to supplement this 
process in maintaining a complete set of tax rates applicable to Enterprise's transactions. 

2.2 Detailed Design Description 

2.2.1 Read and Store Third Party Rates in the Database 

A program will be developed in Pro*C to load pertinent information from the periodic RIA file into a 
single database table. A UNIX shell script will be developed to execute the Pro*C module and 
perform any other supporting functions (e.g., sorting, file maintenance, etc.). This process will be 
comprised of the following specific functions: 

• Read the periodic RIA ASCII, sequential file. 

hi • For all records on the file, store only the information required by Enterprise. For example, 
II where sales, rental, rental transit, and use rates are provided, only rental and rental transit 
M rates would be stored in the database, since sales and use taxes will not be applicable to 
\ll Enterprise's transactions. 

til | 

P • Set the add, change, delete indicator for each record loaded into the VNDR_TAX_RATE 
H| table. 

y | • Set the update applied indicator for each record loaded into the VNDR_TAX_RATE table. 

». • Compress and rename the RIA file to save disk space and indicate that the file has been read 
* and loaded into the database. 

.!!! 

||2.2.2 Build and Assign Initial Hierarchies 

h ■ . 

■mi ■ 

LhA program will be developed to perform conversion of the data loaded into the VNDRJTAXJtATE 
table. A UNIX shell script will be developed to execute the program and perform any other 
supporting functions (e.g., sorting, file maintenance, passing of parameters, etc.). The conversion 
process will perform the following specific functions: 

• Create the database entries (i.e. areas) required to represent each U.S. taxing jurisdiction 
having a zip code in which Enterprise operates a branch. Areas will be created for the 
appropriate group, state, county, or city level. The process will support dynamic specification 
of the lowest level for which areas will be built for a given state. The lowest level to be built 
will be specified for each state by Enterprise. Where multiple rates exist for a given county, 
separate county areas, one for each unique combination of the county and county link code, 
will be created. 

• Link these jurisdictions together, where appropriate, to create complete hierarchies (e.g., 
group, state, county, city) that can be used to determine the appropriate taxes for a transaction 
in any given jurisdiction. Hierarchies will include the Enterprise group, thereby allowing 
each group to maintain its own rates for any jurisdictions in which it operates. 
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• Create the database entries required to associate each branch with its specific areas and 
hierarchy. Each branch should be associated with all levels of the hierarchy down to the 
lowest level specified for the state in which it resides. 

The areas and hierarchies used to represent U.S. tax jurisdictions will be created according to the 
following rules: 

For all distinct combinations of U.S. group, state, county, and zip code for active U.S. branches* in 
the ofcdirbr table: 

• Create a tax and surcharge area for the group if it does not exist in the usr_dmd_areas table. 

• Create a tax and surcharge area, under the group, for the state if it does not exist in the 
usr dfhd areas table. 


5 : 


• Create a tax and surcharge area, under the group and state, for each county found on an RIA 
record having the same state and zip code if the area does not exist in the usr_dftid_areas 
table. In most cases, it will be sufficient to simply use the county from the ofc_dir_br row. 
However, in the case of counties for which multiple rates exist, separate areas will be created 
for each county/link code combination since link code distinguishes the various parts of the 
SI county with different rates. Therefore, the RIA table will be checked to see if more than one 
U rate exist on the RIA file for the associated county. If so, multiple county areas will be 
created, one for each link code associated with the county. 


fa?. 

m 


Create a tax and surcharge area, under the group, state, and county, for any city found on an 
RIA record having the matching state, zip code, and county. 


)(,<* Active U.S. branches will include those branches associated with a grp_id between 0 and 69, a 
grp_typ_cde = 'B', a "dr_br_typ_ind" = 'Y\ and stat_cde = 'A'. 

The association of each branch to its tax jurisdictions will be made according to the following rules: 
For each U.S. branch, create a row in the bil_tas_areas table that identifies: 

• The group with which the branch is associated 

• The state with which the branch is associated 

• The county with which the branch is associated, if the matching county is found in a row in 
the RIA data having the same state and zip code and the hierarchy is to be built to at least the 
county level for the particular state. In the case of a multi-rate county, the county will be 
populated in the bil_tas_areas row only if a single county/link code combination is associated 
with the branch's state, zip code, and county. 

• The city with which the branch is associated, if all of the following are true: 

1 . The branch's mailing city matches either the local taxing jurisdiction or the location name 
in an RIA record with the same state, county, and zip code. In the case of a multi-rate 
county, county refers to combination of county and link code. 
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2. The city rate is > 0.0 or (the city rate = 0 and there are no other RIA records for the city 
with a rate > 0 in the same state, county, and zip code). 

3. The hierarchy is to be built to the city level for the particular state. 

If a branch cannot be associated with an RIA record that identifies the lowest level in the hierarchy 
for the state in which the branch resides, the branch will not be assigned to any levels of the hierarchy 
(i.e., a bil_tas_areas row will be inserted only if the branch can be associated with all appropriate 
levels of the hierarchy) and an appropriate message will be generated. 

2.2.3 Load and Maintain RIA Tax Rates 

A program will be developed to load and maintain tax rates based on the RIA-supplied data. A 
UNIX shell script will be developed to execute the program and perform any other supporting 
functions (e.g., sorting, file maintenance, passing of parameters, etc.). This process will perform the 
following specific functions: 


i a 


II? «• 


2 ( 


Create the database entries required to store the tax rates and associated tax type (i.e., rental 
or rental transit tax) for branches located in those states that are not specifically excluded. 
States may be excluded from this portion of the process if the RIA rates are not applicable. 

Compare the current RIA rates to those in the database and update the database if a rate 
change has taken place. Rates will be updated by populating an end date associated with the 
old rate and creating a new row with an effective date, but no end date, to store the new rate. 
A check will be made to ensure that the rate has not been manually changed by Enterprise 
with the intention of overriding the RIA rate. If the rate has been modified, as indicated by a 
flag on the tax code (rate) entry in the database, this process will skip the rate update and 
preserve the manually maintained rate. A rate update will be performed only if a single, 
active rate of the same type (i.e., rental or rental transit tax) exists for the area or, if more than 
one exists, the update will take place when only one corresponding rate is not being manually 
maintained. For example, if two active rental tax rates exist for a given jurisdiction, and both 
have the flag set to indicate they are being maintained manually, the load process will not 
apply an update to either rate. However, if only one rate has the flag set, the update would be 
applied to the rate for which the flag is not set. If a rate has been manually modified and is 
subsequently set to revert to the RIA rate, the effective date provided by RIA will be used 
unless it is less than the end date of the manual update, in which case the current date will be 
used as the effective date. If a delete transaction is received for a particular jurisdiction, and 
there are no other RIA records for that jurisdiction, the associated tax rate rows in the 
database will be updated with an end date. If the active rate indicates it is being maintained 
manually, no update to the end date will be performed (i.e., the rate will not be inactivated by 
the load process). 
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2.3 Database Table Impacts 


The following database table changes are required. 

2.3.1 VNDRTAXRATE 

This new table will be used to store the required data elements from the complete file or updates-only 
file as received from RIA. A program will be developed to populate this table from the ASCII file 
(complete file or monthly updates) received periodically from RIA. The table will be comprised of 
the following columns: 

VARCHAR2(6) 
VARCHAR2(15) 
VARCHAR2(6) 
VARCHAR2(6) 
VARCHAR2(12) 
VARCHAR2(26) 
VARCHAR2(26) 
NUMBER(6,4) 
NUMBER(6,4) 
DATE 

VARCHAR2(26) 
NUMBER(6,4) 
NUMBER(6,4) 
DATE 

NUMBER(6,4) 
VARCHAR2(2) 
VARCHAR2(2) 
VARCHAR2(1) 
VARCHAR2(1) 
VARCHAR2(3) 
VARCHAR2(2) 
VARCHAR2(30) 
VARCHAR2(1024) 
DATE 

VARCHAR2(30) 
VARCHAR2(1024) 
DATE 

2.3.2 LRD BR PROF 

The following column will be added to the LRD_BR_PROF table. 

COUNTY VARCHAR2(26) 


VNDR_ST_CDE 
POSTL_ZONE_CDE 
POSTL_ZONE_POP_SEQ_NBR 
U CNTRY_ISO_CDE 
GJ CNTRY_SUBDIV_SHRT_NAM 
LCL_TAX_JURIS_NAM 
LCLNAM 

i|| LCL_RENT_TAX_RATE_AMT 
»j- LCL_TRANS_RENT_TAX_RATE_AMT 
£j LCL_TAX_RATE_EFF_DTE 
k I. CNTYTAXJURISNAM 

CNTY_RENT_TAX_RATE_AMT 
CNTY_TRANS_RENT_TAX_RATE_AMT 
CNTY_TAX_RATE_EFF_DTE 
COMBINED_RENT_TAX_RATE_AMT 
t LCLTAXRATEXCPTCDE 
IP CNTY_TAX_RATE_XCPT_CDE 
21 UPD_APLY_IND 
Wk/ CHNGTYPIND 
CNTY_LINK_CDE 
RECORDSTATUS 
CREATED_BY 
CREATEMODULE 
CREATETIMESTAMP 
UPDATED_BY 
UPDATEMODULE 
UPDATE TIMESTAMP 


'si. 

n 
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2.3.3 BIL TAS AREAS 


The following changes are required to the BIL_TAS_AREAS table. 


COUNTYJD 
CITYJD 
DIST ID 


allow nulls 
allow nulls 
allow nulls 


2.3.4 TAS USR DFND AREA 

A new table, TAS_USR_DFND_AREA (tax and surcharge user defined area locations) will be 
created with the following columns: 


ofcriven the general rule that "intelligence" will not be built into database key values, this mechanism 
f Jwill allow each user defined area created for tax and surcharge purposes to be associated with the 
^geographic area(s) it represents. For example, if a tax and surcharge area were created to represent 
Jefferson County, Missouri, the area id (without any built-in intelligence) might simply be a 
sequential value such as 0000012345. Other than a text description, there would be no reliable way 
to programmatically determine which group, state/province, county, or city this area represents. 

The new TAS_USR_DFND_AREA table essentially adds these attributes to the user defined areas in 
lieu of building them into (i.e., placing intelligence in) the area id. Since this table will be used by 
the tax rate maintenance process to determine whether an area exist for a specific tax jurisdiction, it 
should be maintained by the forms used to maintain tax and surcharge areas and hierarchies. 

2.3.5 TX_CDS 

A new column will be added to the TX_CDS table to indicate that a rate has been modified by the 
maintenance forms and that the modification is not to be overwritten by the RIA rate load process. 

MNL_MAINT_IND VARCHAR2(1) 


CNTRY_ISO_CDE 
AREAJD 
ATY_AREA_TYP 
GRPJD 

CNTRY_SUBDIV_SHRT_NAM 

CNTY_NAM 

CITY_NAM 

CREATEDJBY 

CREATE_MODULE 

CREATEJTIMESTAMP 

UPDATEDJBY 

UPDATE_MODULE 

UPDATE TIMESTAMP 


VARCHAR2(6) 
VARCHAR2(10) 
VARCHAR2(10) 
NUMBER(10) 



VARCHAR2(12) 

VARCHAR2(34) 

VARCHAR2(34) 

VARCHAR2(30) 

VARCHAR2(1024) 

DATE 


VARCHAR2(30) 

VARCHAR2(1024) 

DATE 
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2.3.6 Oracle Sequences 

A new Oracle Sequence number, UDA SEQ NBR will be added. This sequence will be used to 
populate the area_id column of the USR_DFND_AREAS (user defined areas) table when rows are 
inserted into the table to represent tax jurisdictions. This sequence will start at a value of 1 and 
increment by 1 each time the next value of the sequence number is used. Note that this sequence 
number will be used to generate the area id for tax and surcharge areas only (i.e., those with an 
AREA TYP = TAS_GRP\ TAS_STPR', <TAS_COUN', 'TAS_COUN', or <TAS_DIST'). 

A new Oracle Sequence number, TXC_SEQ_NBR will be added. This sequence will be used to 
populate the tx_cd column of the TX_CDS (tax codes) table when rows are inserted into the table to 
represent the individual taxes. This sequence will start at a value of 1 and increment by 1 each time 
the next value of the sequence number is used. 

2.3.7 List of Excluded States 


jfAs part of the maintenance forms development, a new table will be added to allow the rate load and 
iijtnaintenance process to determine whether each state is included or excluded from the process. At 
ptninimum, this table will include the following attributes: 


M- CNTRY_SUBDIV_SHRT_NAM VARCHAR2(12) 

Ul INCL_EXCL_IND VARCHAR2(1) 


51 

WS 

Hi 

111 
ill 

M 
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2.4 Inputs 

The main inputs to the third party tax rate conversion processes are the RIA tax rate file and 
Enterprise's branch location information. The primary inputs to each major process are described 
and discussed below. 

2.4.1 Read and Store Third Party Rates in the Database 

The following inputs will be used by the process that will load the RIA information from a UNIX flat 
file into an Oracle database table: 


RIA Sales and Use Tax FUe (complete file or periodic updates) 

I^This is a fixed-length (528 characters for the complete file, 529 characters for the update file) ASCII 
pfile having a single record for each state, and additional records for each local/county jurisdiction. 
EjThe state records are of the same length as the local/county records, with the state-level rates 
ijlappearing in the corresponding "local" fields. The "county" fields of the state records are left blank 
iljor are filled with zeros. Each record ends with carriage return line feed characters. 


JP5 

M 


3 'i ?, 

3^ ii 
ill 


Field 

Field Description 

Starting 
Position 

Field 
Length 

1 

State Numerical Code 

1 

2 

2 

Zip Code 

4 

5 

3 

Population Indicator 

10 

2 

4 

Local Taxing Jurisdiction Name 

13 

26 

5 

Location Name 

40 

26 

6 

Current Local Sales Rate 

67 

7 

7 

Current Local Sellers' Use Rate 

74 

7 

8 

Current Local Services Rate 

81 

7 

9 

Current Local Rental Rate 

88 

7 

10 

Current Local Consumers' Use Rate 

95 

7 

11 

Current Local Transit Sales Rate 

102 

7 

12 

Current Local Transit Sellers Use Rate 

109 

7 

i 13 

Current Local Transit Services Rate 

116 

7 

14 

Current Local Transit Rental Rate 

123 

7 

15 

Current Local Transit Consumer Use Rate 

130 

7 

16 

Current Local Effective Date (mmddyyyy) 

138 

8 

17 

County Taxing Jurisdiction 

147 

26 

18 

Current County Sales Rate 

174 

7 

19 

Current County Sellers' Use Rate 

181 

7 

20 

Current County Services Rate 

188 

7 

21 

Current County Rental Rate 

195 

7 

22 

Current County Consumers' Use Rate 

202 

7 

23 

Current County Transit Sales Rate 

209 

7 

24 

Current County Transit Sellers Use Rate 

216 

7 

25 

Current County Transit Services Rate 

223 

7 


Last Save Date: 10/17/2001 2:03 PM 


Page 12 of 39 


Sales Tax Conversion Design 


Enterprise 


rent-a-car 


ECARS v2.0 - Accurate Out the Door Pricing 
Detailed Design Specification 


perotsystems 


Field 

Field Description 

Starting 
Position 

Field 
Length 

26 

Current County Transit Rental Rate 

230 

7 

I 27 

Current County Transit Consumers Use Rate 

237 

7 

28 

Current County Effective Date (mmddyyyy) 

245 

8 

29 

Current Combined Sales Rate 

253 

7 

30 

Current Combined Sellers Use Rate 

260 

7 

31 

Current Combined Services Rate 

267 

7 

32 

Current Combined Rental Rate 

274 

7 

33 

Current Combined Consumers Use Rate 

281 

7 

34 

Prior Local Sales Rate 

288 

7 

35 

Prior Local Sellers' Use Rate 

295 

7 

36 

Prior Local Services Rate 

302 

7 

37 

Prior Local Rental Rate 

309 

7 

38 

Prior Local Consumers' Use Rate 

316 

7 

39 

Prior Local Transit Sales Rate 

323 

7 

40 

Prior Local Transit Sellers Use Rate 

330 

7 

41 

Prior Local Transit Services Rate 

337 

7 

42 

Prior Local Transit Rental Rate 

344 

7 

43 

Prior Local Transit Consumers Use Rate 

351 

7 

44 

Prior Local Effective Date (mmddyyyy) 

359 

8 

45 

Prior County Sales Rate 

367 

7 

46 

Prior County Sellers' Use Rate 

374 

7 

47 

Prior County Services Rate 

381 

7 

48 

Prior County Rental Rate 

388 

7 

49 

Prior County Consumers' Use Rate 

395 

7 

50 

Prior County Transit Sales Rate 

402 

7 

51 

Prior County Transit Sellers Use Rate 

409 

7 

52 

Prior County Transit Services Rate 

416 

7 | 

53 

Prior County Transit Rental Rate 

423 

7 

54 

Prior County Transit Consumers Use Rate 

430 

7 

55 

Prior County Effective Date (mmddyyyy) 

438 

8 i 

56 

Prior Combined Sales Rate 

446 

7 

57 

Prior Combined Sellers Use Rate 

453 

7 

58 

Prior Combined Services Rate 

460 

7 

59 

Prior Combined Rental Rate 

467 

7 

60 

Prior Combined Consumers Use Rate 

474 

7 

61 

County Link Code 

482 

3 

62 

Local Exception Code 

486 

2 

63 

County Exception Code 

489 

2 

64 

Local Indicator 

492 

1 

65 

County Indicator 

494 

1 

66 

Local Transit Code 

496 

2 

67 

County Transit Code 

499 

2 

68 

Local Locally Administered Code 

502 

1 

69 

County Locally Administered Code 

504 

I 

70 

Local Tax Code 

506 

10 

71 

County Tax Code 

517 

10 

72 

Carriage Return Character 

527 

1 

73 

Line Feed Character 

528 

1 
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The record layout for the update file differs slightly from the complete file in that there is an 
additional field, the add/change/delete indicator, as shown below: 


Field 

Field Description 

Starting 

Field 



Position 

Length 

72 

Add, Change, Delete Indicator 

527 

1 

73 

Carriage Return Character 

528 

1 

74 

Line Feed Character 

529 

1 


CNTRY_SUBDIV 

This table will be read to facilitate conversion of the two character numeric state code used by RIA to 
the two character alphabetic code used by Enterprise. 


Program Parameters 


The read and store third party rates process will require a command line argument (parameter) to 
lobtain the name of the RIA file to be processed. The script that executes this process will 
[automatically determine the name of the file to be processed, provided it is located in the appropriate 
^directory and is named according the currently specified RIA standards, and pass it as a parameter to 
yithe program that will perform the required processing. 

t ^Environment Variables 


: s a 


m 

mfflae read and store third party rates process will require a UNIX environment variable, UNJPW, to 
ppbtain the userid and password (in the form userid/password) required to log on to the appropriate 
jjldatabase. This variable must be set and exported prior to submitting the script that runs this process. 

2.4.2 Build and Assign Initial Hierarchies 

The following inputs will be used by the process that will build the initial tax jurisdiction areas and 
hierarchies and make the initial assignment of branches to appropriate hierarchies: 

OFCJMR_GRP 

This table will be read in combination with the ofcjiir _br table to obtain information about the 
appropriate group and branches for which tax jurisdiction areas will need to be built. This 
information will be used in conjunction with the RIA tax data to determine whether there are 
applicable state and local rental and rental transit taxes, based on the branches' locations. 

OFCJHRJBR 

This table will be read to obtain basic branch information such as branch id and location information 
such as state, county, city, and zip code. This information will be used in conjunction with the RIA 
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tax data to determine whether there are applicable state and local rental and rental transit taxes, based 
on the branches' locations. 

LRDJORG 

This table will be read to determine the PeopleSoft id associated with each branch. The PeopleSoft 
id will be used when inserting a row into the STN CNTR table as each branch is assigned to its 
respective area hierarchy. 

LRD BR PROF 

This table will be read to determine the county associated with each branch. The county will be used 
in conjunction with the RIA data to determine the appropriate county areas to build. 

VNDRTAXRATE 

CjThis new table will be used to store, in a database format, required data elements from the RIA tax 
j={rate file. This will facilitate retrieval of the data based on selection and sort criteria. In addition, it 
yfwill facilitate the ongoing maintenance of RIA tax rates in that the process used to load this table 
| jfrom the RIA file could be designed to apply add, update, and delete transactions from the available 
^jupdates-only file, thereby maintaining a complete, current set of RIA rates readily available in the 
yjdatabase. 

si 

HList of States and Associated Hierarchy Levels 

111; 

pjA hierarchy level indicating the lowest level for which the tax jurisdiction areas will be specified for 
ppach state. Since this information will be used only by the process to build and assign branches to 
j'Jhe initial hierarchies, it will be supplied in the form of a UNIX flat file rather than a permanent 

database table. The name of the file will be passed as a command line argument (parameter) to the 

program mat will build and assign the tax hierarchies. 

A record for each state should be present in this file. The absence of a valid record for a given state 
will cause the level to default to 0, indicating that no hierarchies are to be build as a result of 
branches in that state. 
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The record format will be as follows: 


Field Name 

Pos. 

Notes 

State Code 

1-2 

Country Subdivision Code (e.g., 'AL') 

Blank 

3 

Should be blank 

Hierarchy Level 

4 

Lowest level to which the hierarchy should be built for 
the state 

0 = no areas will be created 

1 = group 

2 = state 

3 = county 

4 = city 


For example, to build the hierarchy to the city level for Alabama the appropriate record would be : 
"AL 4". ' 

\mk 

j ^Program Parameters 

i^i i 

KiThe build and assign initial hierarchies process will require a command line argument (parameter) to 
Ipbtain the name of the file containing the list of states and associated hierarchy levels. The script 
Sjthat executes this process will require this information as a command line parameter and pass it to 
fjlhe program that will perform the required processing. 

Si 

Environment Variables 

3-1 8 

« {The build and assign initial hierarchies process will require a UNIX environment variable, UN JP W, 
|io obtain the userid and password (in the form userid/password) required to log on to the appropriate 
j! {database. This variable must be set and exported prior to submitting the script that runs this process. 

2.4.3 Load and Maintain RIA Tax Rates 

The following inputs will be used by the process that will load and maintain RIA-supplied tax rates: 
VNDR_TAX_RATE 

This new table will be used to store, in a database format, required data elements from the RIA tax 
rate file. This will facilitate retrieval of the data based on selection and sort criteria. In addition, it 
will facilitate the ongoing maintenance of RIA tax rates in that the process used to load this table 
from the RIA file could be designed to apply add, update, and delete transactions from the available 
updates-only file, thereby maintaining a complete, current set of RIA rates readily available in the 
database. 
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TAS USR DFND AREA 


This table will effectively add the group id, state/province code, county name, and city name as 
attributes to the tax and surcharge areas. The build and assign initial hierarchies process will insert 
one row into this table for each tax and surcharge area it creates. The load and maintain RIA tax 
rates process will use this table to determine whether the taxing jurisdiction area exists for each rate 
to be maintained. If the associated area does not exist in the database, maintenance for the rate will 
be skipped and a message written to an exception file . 

TX_CDS 

Although this is the primary output of the load and maintain RIA rates process, it is also an input 
used to determine the type of update required, if any. If no row corresponding to the RIA rate exists 
in this table, it will be inserted. If the corresponding row exists and the rate matches that of the RIA 
rate being processed, no update is required. If the row exists but the rate is different, the rate in this 

liable will be updated to reflect the new RIA rate provided the manual maintenance indicator is not 

fclsetto 6 Y\ 


11 


tist of States to Exclude from the Load Process 


m - 

JfThe states to be excluded from the tax rate load and maintenance process (i.e., those for which RIA 
I s lates will not be used) will be stored by the maintenance forms in a database table. The load and 
J maintain RIA rates process will use this table to determine whether to load and maintain the RIA- 
^Supplied rates for each state. The table name and specific details have not been determined. 


HI. 


fl Environment Variables 


lis 


The load and maintain RIA tax rates process will require a UNIX environment variable, UN_PW, to 
obtain the userid and password (in the form userid/password) required to log on to the appropriate 
database. This variable must be set and exported prior to submitting the script that runs this process. 
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2.5 Outputs 

The main outputs of the third party tax rate conversion processes are areas and hierarchies 
representing the taxing jurisdictions common to the RIA data and Enterprise's branch locations, the 
database entries needed to associate branches with their respective hierarchies, and current third party 
tax rates in the database. The primary outputs of each major process are described and discussed 
below. 

2-5.1 Read and Store Third Party Rates in the Database 
VNDRJTAX_RATE 

This new table will be used to store, in a database format, required data elements from the RIA tax 
j^rate file. This will facilitate retrieval of the data based on selection and sort criteria. In addition, it 
CI will facilitate the ongoing maintenance of RIA tax rates in that the process used to load this table 

jfrom the RIA file could be designed to apply add, update, and delete transactions from the available 
I¥updates-only file, thereby maintaining a complete, current set of RIA rates readily available in the 
•Jf database. 

hi 

3 ILog File 

mi .. ■■ 

"si 

\ K \A log file will be generated by the read and store third party rates in the database process to provide 
lljbasic processing information such as start and end time, any informational messages, and an 
Jindication of successful completion. 


213 5 

5 S 


TError File 


An error file will be generated by the read and store third party rates in the database process to 
provide information about any errors that occur during processing. 

2.5.2 Build and Assign Initial Hierarchies 
USRJ)FND_AREAS 

For tax purposes, this table is used to represent the geographic areas in which a branch is located. 
The load process will insert a row into this table for each geographic area in which a branch (or 
counter) is located for tax purposes. For example, if a branch is located in the state of Illinois, Cook 
County, and the city of Chicago, a row must be inserted for each of these areas if the row does not 
exist. Continuing the example, if rows have previously been inserted, for Illinois, and Cook county, 
then only the city-level row for Chicago would be inserted. 
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TAS USR DFND AREA 


This table will effectively add the group id, state/province code, county name, and city name as 
attributes to the tax and surcharge areas. The load process will insert one row into this table for each 
tax and surcharge area it creates. 

AREAJRLTNS 

Hierarchies of areas are established through rows in the AREAJRLTNS table. For example, the 
relationships between Group 15, Illinois, Cook County, and Chicago would be established through 
rows in this table. Group 1 5 would be established as the parent of Illinois, Illinois the parent of Cook 
County, Cook County a parent of Chicago, thereby creating a hierarchy ordered from most general to 
most specific geographic area. 

BIL JTAS_AREAS 

H 

r iThis table is used by the tax engine to obtain the tax area ids applicable to a given branch. The load 
Ciprocess will insert a row into this table for each branch. 

m . 

t?STN€NTR 

V| 

' jThis table provides a mechanism to allow for a single branch (known as a station in VRS) to have 
counters in more than one geographic area. Prior to the initial conversion of RIA tax rates, this table 
^.will be empty. One row will be inserted into this table by the load process for each branch. The 
rf fstation id will be populated with the unique PeopleSoft branch id. The area id will be populated with 
*iarea id of the lowest level of the hierarchy (state, county, or city) associated with the branch. The 
! Wea type will be populated with "TASJSTPR" (tax and surcharge area - state), "TASCOUN" (tax 
pkad surcharge area - county), or "TAS__CITY" (tax and surcharge areas - city) based on the hierarchy 
|r * level associated with the areajd. 

Log File 

A log file will be generated by the build and assign initial hierarchies process to provide basic 
processing information such as start and end time, any informational messages, and an indication of 
successful completion. 

Error File 

An error file will be generated by the build and assign initial hierarchies process to provide 
information about any errors that occur during processing. 


IJ4 


Last Save Date: 10/17/2001 2:03 PM 


Page 19 of 39 


Sales Tax Conversion Design 


Enterprise 


rent-a-car 


ECARS v2.0 - Accurate Out the Door Pricing pSFOtSVSteiTIS" 

Detailed Design Specification 


Summary Reports 


Various reports will be required to summarize the results of the tax rate conversion and maintenance 
processes and support on-going manual maintenance of related tax rates. A separate design 
document will be prepared to address any reporting requirements. 

2.5.3 Load and Maintain RIA Tax Rates 
TX_CDS 

This table is used by the tax engine to retrieve the appropriate tax rates for a given area. This is the 
final destination for the RIA rates loaded by the processes described in this document. Once the 
country, state/province, county, city, and district area ids are known for a given branch, all applicable 
taxes (except those implemented as surcharges) for those areas can be obtained from this table. The 
load process will insert a row into the TX_CDS table when no row exists for the rate being 
|4 processed. The process will update the end date on an existing row and insert a row with the new 
Urate if the corresponding rate for the area has changed and the rate is not being manually maintained. 
Cf If a rate is deleted or changed to 0% in the RIA data, the corresponding row in the TX_CDS table 
will not be deleted. Instead, the load process will set the inactive date to the effective date of the 
change. 


; Log File 

si 

biA log file will be generated by the load and maintain RIA tax rates process to provide basic 

il jprocessing information such as start and end time, any informational messages, and an indication of 

illsuccessful completion. 

ill 

Error File 


An error file will be generated by the load and maintain RIA tax rates process to provide information 
about any errors that occur during processing. 
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2.7.1 Read and Store Third Party Rates in the Database 

This process will be executed each time a new file is received from RIA. The objective of this 
process is to ensure that the VNDR JTAX_RATE table always contains the complete, current rental 
and transit tax rates as supplied by RIA, 

For the initial load, a complete tax rate file will be required. When processing a complete file, the 
load process will treat each record as an "add' 5 record and insert the applicable data into the table. 
Any rows existing in the table will be deleted prior to loading a complete file. 

When processing an update file (one containing only the changes since the previous file was issued), 
the load process will use the add, change, delete indicator on each record to determine the 
appropriate action to take with respect to the record as follows: 

• If the value of this field is an 4 A 5 the pertinent data will be inserted into the table, the add, 
U change, delete indicator set to * A' and the update applied indicator set to *N\ If a row already 
p exists in the table with the same state, zip, and population indicator values, an appropriate error 
|| message will be produced. 

[;[ • If the value is a 6 C S , the appropriate rate, if found, will be updated to reflect the latest 

If' information, the add, change, delete indicator set to 6 C and the update applied indicator set to 

tj TSP. If the corresponding rate is not found, an appropriate error message will be produced. 

|jj • If the value is a T>', the corresponding row, if found, will be updated by setting the add, change, 

I delete indicator to D' and the update applied indicator to 'N\ If the row is not found, an error 

j* message will be produced. 

pf The following tables illustrate the process that will store and maintain the RIA tax rate data in the 
| J VNDRJTAXJRATE table. The purpose of this table is to maintain a complete, current set of 
?l applicable RIA tax rates in a manner that facilitates systematic access to this information. The 
1 creation and maintenance of the structures (i.e., areas, area hierarchies, tax codes, etc.) required to 
provide the VRS tax engine access to these rates is described in a subsequent process. 

One of two input file formats may be used as input to this process; a complete file containing all rates 
or an update file containing only those records for which a change is required. Assume that a 
complete RIA file is received and contains the records shown in the following table. 


RIA File (complete) 


State 

Zip 

Pop. 
Ind. 

City 

County 

Local 
Rental 
Rate 

Local 
Transit 
Rental 
Rate 

County 
Rental 
Rate 

County 
Transit 
Rate 

Add 
Change 
Delete 

MO 

00000 

00 

MISSOURI 


4.2250 

0.0000 

0.0000 

0.0000 


MO 

63011 

00 

BALL WIN 

SAINT LOUIS 

1.5000 

0.0000 

L00O0 

0.0000 


MO 

63011 

01 

ELLISVILLE 

SAINT LOUIS 

1.5000 

0.0000 

1.0000 

0.0000 
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If this file is used as input to the initial load process, all existing rows in the VNDRJTAXJRATE 
table will be deleted and all records on the RIA file will be treated as Add transactions. The 
VNDRJTAXJRATE table would contain the rows summarized in the following table. Note the 
values of the "add, change, delete" and "update applied" columns. These will be used by the process 
that builds and maintains the tax rates to determine which transactions in the VNDRJTAXJRATE 
table require processing and what type of processing is required. 


RIAJDATA table (before rate load process) 


State 

Zip 

Pop. 
Ind. 

City 

County 

Local 
Rental 
Rate 

Local 
Transit 
Rental 

Rate 

County 
Rental 
Rate 

County 
Transit 
Rate 

Add 
Change 
Delete 

Update 
Applied 

MO 

00000 

00 

MISSOURI 


4.2250 

0.0000 

0.0000 

0.0000 

A 

N 

MO 

63011 

00 

BALLWIN 

SAINT LOUIS 

1.5000 

0.0000 

1.0000 

0.0000 

A 

N 

MO 

63011 

01 

ELLISVILLE 

SAINT LOUIS 

1.5000 

0.0000 

1.0000 

0.0000 

A 

N 


jj*. After the process that builds the tax rate structures is run, the "update applied" column is set to Y to 
■j! J indicate that all required action to process the rate transaction is complete. 

jit RIA_DATA table (after rate load process) 


State 

Zip 

Pop. 
Ind. 

City 

County 

Local 
Rental 
Rate 

Local 
Transit 
Rental 

Rate 

County 
Rental 
Rate 

County 
Transit 
Rate 

Add 
Change 
Delete 

Update 
Applied 

MO 

00000 

00 

MISSOURI 


4.2250 

0.0000 

0.0000 

0.0000 

A 

Y 

MO 

63011 

00 

BALLWIN 

SAINT LOUIS 

1.5000 

0.0000 

1.0000 

0.0000 

A 

Y 

MO 

63011 

01 

ELLISVILLE 

SAINT LOUIS 

1.5000 

0.0000 

1.0000 

0.0000 

A 

Y 


H Assume that an update RIA file is received and contains the records shown in the following table. 
RIA file (update) 


State 

Zip 

Pop. 
Ind. 

City 

County 

Local 
Rental 
Rate 

Local 
Transit 
Rental 

Rate 

County 
Rental 
Rate 

County 
Transit 
Rate 

Add 
Change 
Delete 

MO 

63105 

00 

CLAYTON 

SAINT LOUIS 

2.2500 

0.0000 

1.0000 

0.0000 

A 

MO 

63011 

00 

BALLWIN 

SAINT LOUIS 

2.5000 

0.0000 

1.0000 

0.0000 

C 

MO 

63011 

01 

ELLISVILLE 

SAINT LOUIS 

1.5000 

0.0000 

1.0000 

0.0000 

D 


If this file is used as input to the load process, any add transactions will simply be inserted into the 
table and the values of the "add, change, delete" and "update applied" columns set to A and N 
respectively. For change and delete transactions, the process will replace the existing row (i.e., the 
row with the same state, zip, and population indicator) with the new information from the RIA 
update file, setting the value of the "add, change, delete" column to a C or D as appropriate and 
setting the value of the "update applied" column to N. The VNDRJTAXJRATE table would contain 
the rows summarized in the following table. 
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RIA_DATA table (before rate load process) 


State 

Zip 

Pop. 
Ind. 

City 

County 

Local 
Rental 
Rate 

Local 
Transit 
Rental 
Rate 

County 
Rental 
Rate 

County 
Transit 
Rate 

Add 
Change 
Delete 

Update 
Applied 

MO 

00000 

00 

MISSOURI 


4.2250 

0.0000 

0.0000 

0.0000 

A 

Y 

MO 

63105 

00 

CLAYTON 

SAINT LOUIS 

2.2500 

0.0000 

1.0000 

0.0000 

A 

N 

MO 

63011 

00 

BALL WIN 

SAINT LOUIS 

2.5000 

0.0000 

1.0000 

0.0000 

C 

N 

MO 

63011 

01 

ELLISVILLE 

SAINT LOUIS 

1.5000 

0.0000 

1.0000 

0.0000 

D 

N 


Again, after the process that builds and maintains the tax rates is run, the "update applied" column is 
set to Y to indicate that all required action to process the rate transaction is complete. 


H RIAJDATA table (after rate load process) 


sag j 
f 1 

"Stale"' 

Zip 

Pop. 
Ind. 

City 

County 

Local 
Rental 
Rate 

Local 
Transit 
Rental 
Rate 

County 
Rental 
Rate 

County 
Transit 
Rate 

Add 
Change 
Delete 

Update 
Applied 

M 

MO 

00000 

00 

MISSOURI 


4.2250 

0.0000 

0.0000 

0.0000 

A 

Y 


MO 

63105 

00 

CLAYTON 

SAINT LOUIS 

2.2500 

0.0000 

1.0000 

0.0000 

A 

Y 


MO 

63011 

00 

BALL WIN 

SAINT LOUIS 

2.5000 

0.0000 

1.0000 

0.0000 

C 

Y 

V s " 

MO 

63011 

01 

ELLISVILLE 

SAINT LOUIS 

1.5000 

0.0000 

1.0000 

0.0000 

D 

Y 


in J 

!«j 2.7.2 Build and Assign Initial Hierarchies 

This process will be executed only during the initial conversion of 3 r party tax data. The objective 
of this process is to automate, to the extent possible, the creation of the database structures necessary 
to represent the hierarchy of taxing jurisdictions and assign branches to those hierarchies. 

Tax and surcharge user defined areas and related hierarchies will be built for those areas in which 
Enterprise has one or more active branches. Therefore, branch data will be the primary source of 
information driving this conversion process. The conversion process will select, from the 
OFCJ3IRJ3R table, the following values for all active rental branches located in the U.S. 


Description 

Column 

Data Type 

Branch Identifier 

BR ID 

varchar2(4) 

Group Identifier 

GRP ID 

varchar2(4) 

County Location * 

COUNTY NAM 

varchar2(34) 

Mailing Address City 

MAIL ADDR TXT 

varchar2(34) 

Mailing Address State Code 

MAIL ST CDE 

varchar2(4) 

Mailing Zip Code 

MAIL ZIP CDE 

varchar2(18) J 


* Obtain from LRD_BRJ>ROF, not OFC_DIRJBR 
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This information will be retrieved in sorted order by group, state, county, city, and zip code. For 
each row retrieved, an attempt will be made to obtain the correct tax jurisdiction information from 
the VNDRJTAX_RATE table. 

The following diagram illustrates the relationships among the database tables comprising the tax and 
surcharge area hierarchies and how branches are associated with their respective tax rates. 
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Continuing the example started above using the sample RIA data, the build and assign initial 
hierarchies process would create the initial tax areas and hierarchies required to store the RIA rates 
and support the VRS tax engine. Assume that only two branches (branches 01 and 02) exist and that 
they are operated by group 01 . The individual rows that would be created as a result of the RIA 
transactions presented above are summarized in the following tables. 

For each taxing jurisdiction, a row will be inserted into the USRJDFND_AREAS table. The area id 
will be system-generated and will be a value selected from an incremental sequence number 
maintained by the Oracle database. After processing the transactions received in the complete RIA 
file described above, the following areas would be created. 

USR DFND AREAS 


iff 4 
33.8 


H 

H 


ATY 

AREA 

AREA 

AREA 

ID 

DESC 

TYP 



TAS GRP 

0000001 

GROUP 01 

TAS STPR 

0000002 

MISSOURI 

TAS COUN 

0000003 

SAINT LOUIS 

TAS CITY* 

0000004 

BALL WIN 

TAS CITY* 

0000005 

ELLISVILLE 


* Note that a city level area will be created for each city on an RIA record having the same state and 
zip code as the branch for which the area is being created. Therefore, city areas may be created for 
U cities in which Enterprise does not operate a branch. 

fit 

III The following rows would be inserted into the TAS_USR_DFND_AREAS table. This table will 
0 allow programmatic determination of the group, state, county, or city for which a specific area was 
recreated. 


TAS USR DFND AREAS 


UDA 
AREA ED 

AREA 
TYPE 

GROUP 
ED 

ISO 
COUNTRY 
CODE 

STATE/ 
PROVINCE 
ID 

COUNTY 

CITY 

0000001 

TAS GRP 

01 

USA 




0000002 

TAS STPR 

01 

USA 

MO 



0000003 

TAS COUN 

01 

USA 

MO 

SAINT LOUIS 


0000004 

TAS CITY 

01 

USA 

MO 

SAINT LOUIS 

BALLWIN 

0000005 

TAS CITY 

01 

USA 

MO 

SAINT LOUIS 

ELLISVILLE 
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In order to build the appropriate hierarchy of taxing jurisdictions, the following rows would be 
inserted into the AREA^RLTNS table to associate Missouri with group 01, St. Louis county with 
Missouri and both Ballwin and Ellisville with St. Louis county. 


ARE A_RLTNS 


UDA 
AREA ID 
PRINT 

UDA 
ATY 
AREA TYP 
PRNT 

UDA 
AREA ID 
CHLD 

UDA 
ATY 
AREA TYP 
CHLD 

0000001 

TAS GRP 

0000002 

TAS STPR 

0000002 

TAS STPR 

0000003 

TAS COUN 

0000003 

TAS COUN 

0000004 

TAS CITY 

0000003 

TAS COUN 

0000005 

TAS CITY 


3 If sufficient information is available to match a branch to one and only one city-level (or the lowest 
pj level specified by Enterprise for the state in which the branch resides) area, the branch will be 
jS J assigned to all areas in the hierarchy in which the city (or other specified level) exists by creating a 
jlj row in the BILJTAS_AREAS table. Rows in this table allow the tax and surcharge engines to 
p| identity the specific areas of the hierarchy in which the branch exists as follows: 

; jBILTAS>REAS 


H 

5 ; 

STN 

STN 

GROUP 

STATE/ 

COUNTY 

CITY 


ID 

CNTR 

AREA 

PROVINCE 

AREA 

AREA 



ID 

ID 

AREA 

ID 

ID 

■Hi 




ID 



m 

01 

1 

0000001 

0000002 

0000003 

0000004 

02 

1 

0000001 

0000002 

0000003 

0000005 


A row would be inserted into the STN_CNTR table for each branch as follows: 


STNCNTR 


STN 

SNT 

STN 

UDA 

UDA 

ID 

CNTR 

CNTR 

AREA 

ATY 


ID 

NM 

ID 

AREA 





TYP 

01 

1 

COUNTER 1 

0000004* 

TAS CITY 

02 

1 

COUNTER 1 

0000005* 

TAS CITY 


* The uda_areajd will be populated with the id of the lowest appropriate level area in the hierarchy. 

The build and assign initial hierarchies process will be executed only during initial conversion. 
Therefore, when the RIA update file described in the example above is received, this process would 
take no further action regarding the maintenance of areas, hierarchies, or the assignment of branches 
to them. 
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2.7.3 Load and Maintain RIA Tax Rates 

This process will be executed each time a new file is received from RIA. The objective of this 
process is to ensure that the tax rates present in the TX_CDS table reflect the applicable tax rates for 
any given point in time for those states for which RIA rates are used. 

Continuing the example from above, the following rows would be inserted into the TXCDS table to 
store the tax rates applicable to each area as specified in the RIA complete file (the start and inactive 
dates used in the examples below are assumed to have come from the RIA files). 


TX_CDS 


TX 

TXTYP 

STRT 

INACTV 

CRY 

EXMP 

UDA 

UDA 

TX 

TAX 

CD 

TX 

DTE 

DT 

ARIMP 

T 

AREA 

ATY 

RT 

CDE 


TYP 



CRY 

IND 

ID 

AREA 


LONG 


CDE 



CD 



TYP 


DSC 

00001 

STAX 

01-MAY-1996 


US 

Y* 

0000002 

TAS STPR 

4.2250 

** 

00002 

STAX 

01-APR-2001 


us 

Y* 

0000003 

TAS COUN 

1.0000 

** 

00003 

STAX 

01-APR-1996 


us 

Y* 

0000004 

TAS CITY 

1.5000 

** 

00004 

STAX 

01-APR-1996 


us 

Y * 

0000005 

TAS CITY 

1.5000 

** 


ifi * The value placed in the exempt indicator will be * Y' for all rates loaded initially loaded by this 
* process. 

r j ** This column will be populated with the location name, hierarchy level, followed by the words 
pj "Sales Tax" for rental tax rates or "Transit Tax" for rental transit tax rates (e.g., SAINT LOUIS 

IP COUNTY, Sales Tax"). 

■m • . • 

f* * For all rows inserted into the TXCDS table, both the TXJNM and CR_CHG_DESC columns will 
be populated with "RENTAL TAX" if the row represents a rental rate or "RENTAL TRANSIT 
TAX" if the row represents a rental transit rate. 

Since this reflects the initial conversion of rates, each row is inserted into the tax_cds table with no 
value specified for the inactive date. In general, if multiple records had been present in the RIA data 
for a given jurisdiction, once the first row is inserted to reflect the rate for that jurisdiction, 
subsequent records would not result in a row being inserted since the appropriate rate for the 
jurisdiction would already be reflected in the table. 

Continuing the example from above, the rows in the tx_cds table would appear as follows after 
processing the RIA update file described above. 


Last Save Date: 10/17/2001 2:03 PM 


Page 35 of 39 


Sales Tax Conversion Design 



ECARS v2.0 - Accurate Out the Door Pricing 
Detailed Design Specification 


perotsystems- 


TX CDS 


TV 

TVTVD 


TXT A i^TI/ 

UN AC rv 

CRY 

EXMPT 

TTTTV A. 

UDA 

T TTV k 

UDA 

TX 

TAX 

CD 

TX 

DTF 


rvlVtiVJll: 



A TV 
Ax X 

JYl 

mi? 


TYP 



CRY 


ID 

AREA 


LONG 


CDE 



CD 



TYP 


DSC 

00001 

STAX 

01-MAY-1996 


US 

Y 

0000002 

TAS STPR 

4.2250 

## 

00002 

STAX 

01-APR-2001 


us 

Y 

0000003 

TAS COUN 

1.0000 

** 

00003 

STAX 

01-APR-1996 

01-MAY-2001 

us 

Y 

0000004 

TAS CITY 

1.5000 

*# 

00006 

STAX 

01-MAY-2001 


us 

Y 

0000004 

TAX CITY 

2.50O0 

*# 

00004 

STAX 

01-APR-1996 

01-MAY-2001 

us 

Y 

0000005 

TAS CITY 

1.5000 

## 

00005 

STAX 

01-MAY-2001 


us 

Y 

0000006 

TAS CITY 

2.2500 

*# 


The update activity to this table can be summarized as follows: 

Add - The add transaction for the city of Clayton resulted in the insertion of a new row, tx_cd 
}*» 00005. This assumes the required area to represent Clayton has been manually created. If the area 
pf did not exist in the database,, the insert into the txjcds table would have been bypassed. 

Jit If a subsequent add transaction were received with the same rate for the city of Clayton within Saint 
p; Louis county, MO (perhaps for a different zip code), no update activity would occur since the rate for 
Q the city would be current (i.e., 2.25%). 

fi Change - The change transaction for the city of Ballwin resulted in the update of an existing row, 
H txjcd 00003, and the insertion of a new row, txjcd 00006 to inactivate the 1 .5% rate and activate the 
01 new 2.5% rate. If the area or rate did not exist in the database, the update to and insert into the 
l Jl txjcds table would have been bypassed. 

Or 
&\ 

P? Delete - The delete transaction for the city of Ellisville resulted in the update of an existing row, 
tx_cd 00004, to inactivate the rate. If the area or rate did not exist in the database, the update to the 
tx_cds table would have been bypassed. 


2.8 Calling Process Variations 

2.8.1 Initial Conversion 

During the initial conversion, all three processes comprising the third party tax rate data conversion 
will be executed. 

2.8.2 On-going, Periodic Updates 

During on-going conversion, only the read and store third party rates in the database and the load and 
maintain RIA tax rates processes will be executed. The build and assign initial hierarchies will not 
be run to support on-going maintenance of tax areas and hierarchies. 
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3.1 Risks 


• The ability to correctly handle exceptions to the rates within the RIA file has not been 
completely addressed. RIA provides various codes and textual explanations to identify 
exceptions that may exist to the rates specified for given jurisdictions. Although the rates are 
being stored at the appropriate taxing jurisdiction level, some exceptions can apply to specific 
portions of a jurisdiction. An addendum will be provided to this document to address the 
extent to which the conversion process can assist in handling these exceptions. 

The processes defined in this document do not support multiple rates for the same tax type for 
different areas of a given city. There is only one such case in the current RIA file. If this is a 
valid situation, it could be handled manually. The same is true if, in the future, similar cases 
arise. However, if the number of cases becomes significant, the amount of manual effort 
could be considerable. 

Assumptions 

RIA's InSource Sales and Use Tax Rate Update Subscription Service files will be used as the 
primary source of tax rates for the third party tax rate data conversion process. 

A complete RIA file will be used to build the initial area hierarchy and tax rates. 
Subsequently, all update files will be processed in order (i.e., updates for any given month 
cannot be processed before processing the prior month's file). 

• A process and/or procedure will exist to place the data (complete or update file) on the CD 
provided by RIA into a specified UNIX file in a specified directory which will be accessible 
by the first of the conversion processes described in this document. 

• The rates used from the RIA data will be the rental rates and rental transit rates. 

• For tax purposes, user defined areas and related hierarchies will be created by the initial RIA 
conversion process only. Any subsequent area and hierarchy maintenance will be handled 
manually. 
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Active U.S. branches for which areas and hierarchies will automatically be created will be 
those branches: 

1 . Present in the OFCJDIRJBR table having: 

2. STAT_CDE = 6 A' 

3. DRJBRTYP JND = 'Y' 

4. GRPJDthatis: 

5. Present on the OFCJ3IRJ3RP table having: 

6. a value between 0 and 69, 

7. GRPjrYP_CDE='B* 

• The conversion process will not build any district level areas. 

• All "counters" for a given branch will reside in the same area for tax purposes (i.e., there will 
be only one row in the STN_CNTR table for each branch). 

• Local tax rates loaded into the tx_cds table from the RIA data will be stored separately, at the 
appropriate county or city level. For example, where both county and city/town rental and 
rental transit taxes are applicable, separate rates will be stored at the appropriate level for 
county rental, county rental transit, city rental and city rental transit taxes. 

• For each state, the conversion process will determine the appropriate level to which the 
hierarchy is to be built based on a file provided by Enterprise. 

• After initial conversion, tax jurisdictions and hierarchies will be maintained manually. 

• Tax rates associated with jurisdictions not present in the RIA data will be maintained 
manually. 

• The third party tax rate conversion process will not associate products (charge items) with tax 
rates. 


# 


County name will be available to the conversion process (i.e., in a database table) in a manner 
in which it can be associated with a given branch. 

If multiple rates are present in one county for the same tax type (i.e., rental tax or rental 
transit tax), the county link code will be used to distinguish the portions of the county with 
various rates. A separate area will be created for each county/link code combination. 

If the same city appears with a non-zero tax rate in more than one county within the same 
state (e.g., Chicago in both Cook and Du Page counties), a separate city-level tax and 
surcharge area will be created for each county. 
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3.3 Issues 


• Some counties in the RIA file have more than one county tax rate depending on the location 
within the county. How these will be handled may require additional discussion. The county 
link code will be used to distinguish the portions of a county with various rates. A separate 
area will be created for each county/link code combination. However, where varying rates 
within a city or county are due to exception codes or the city or county indicator values in the 
RIA file, may need a method of handling these, depending on whether RIA rates will be used 
for these states and whether such exceptions are applicable to Enterprise. 

• How will cities having multiple tax rates in the RIA file be handled? There appears to be 
only one instance of this. This should be confirmed with RIA (or the taxing jurisdiction) and, 

|,i if correct, a means of handling this situation should be determined. 


m 
ni 


pis 
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Gap ID 



20 

Surcharge Engine 

VRS does not stop charging License fee after it's recouped 

21 

Surcharge Engine, Tax Engine 

Ontario Fuel Tax Requirements 

22 

Surcharge Engine 

Tax and Surcharges should be assessed based on Transaction type' 

23 

Surcharge Engine, Tax Engine 

Need to support taxes based on vehicle type 

25 

Surcharge Engine, Taxes Engine 

Allow group level maintenance of Taxes & Surcharges 1 

27 

Surcharge Engine, Tax Engine 

Need to provide functionality to retain a historical perspective for any 
date in time to track. 

29 

Surcharge Engine, Tax Engine 

The system must maintain a history of Tax and Surcharge information 

31 

Surcharge Engine 

Provide minimum and maximum vehicle license fee surcharge per day 

141 

Surcharge Engine, Tax Engine 

Surcharges & Taxes based on Registration for North and South 
Carolina vehicles 
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1.1 Overview 

The purpose of this document is to provide detailed design specifications of how Surcharge Engine 
component of VRS will be utilized in calculating all surcharges for all applicable lines of businesses. 
The scope of this document is to present the high level design of Surcharge Engine and to address all 
the gaps identified during Gap Analysis, that are part of iteration 3 as defined in 'Gaps Addressed 
Section' of this document. 

M 1.2 Dependencies 

CI 

gj In order to implement the functionality addressed in this document, the processes calling the 
jvj surcharge engine must be modified to accommodate the API changes described herein. 

in 

VHP 

M 1.3 Data Conversion 


Enterprise decided not to convert data from its TX07 system. Data setup for surcharges could be 
PI done manually using data maintenance screens and/or by collecting all applicable surcharges into 
jj j spreadsheets for each group, then using scripts to load them into the surcharges data model. 


1.4 Impact Analysis 

The current VRS version of the surcharge engine consists of a main surcharge service module and an 
application interface (API) to this module. The engine also reads several tables from an Oracle 
database for retrieving surcharge related data. For performance reasons, no transaction related data is 
written to the database inside the engine. The engine returns all the calculated values to the caller 
processes. 

For Enterprise, the VRS code requires some change to meet the business needs as described in the 
gaps. To resolve the gaps, changes will be required to the following areas: the surcharge data model, 
API to the engine, and the surcharge service module. 
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2.1 Overview 


CI 


?1$ 5" 


hi 


3 s§ 

m 


It is envisaged that all the applications that need to calculate surcharges will call the surcharge 
engine. The primary function of the surcharge engine is to calculate surcharges based on the specific 
input parameters passed to it. The surcharge engine retrieves and computes applicable surcharges 
based on the inputs and returns the list of surcharges to the caller. The surcharge engine is called by 
the charge engine for every rental charge line. This module provides the functionality to calculate 
surcharges at five levels: group, state, county, city and district. The surcharge engine also supports 
vehicle specific surcharges. 

In addition, the tax engine does not currently support varying taxes based on various criteria (e.g., 
vehicle cost.) To an extent VRS can support this by implementing such taxes as surcharges. The 
surcharge engine has support for flexibility in calculation rules and examples of this have been used 
in VRS to date. In order to resolve some identified gaps this functionality will be implemented at 
Enterprise. This actually means populating surcharge tables with tax data (e.g. schg_cds 5 calcrls, 
etc.) The surcharge engine then would pick up and process this data, not the tax engine. In these 
cases, the resultant charge will still be a tax; it just allows use of the surcharge engine's more flexible 
calculations to compute the taxes. A little extra care should be given in these cases to consider tax 
on tax or tax on surcharge implications. For example, if such a tax should apply to some other 
surcharge (i.e. a tax on surcharge scenario) then this tax would actually get set up as a surcharge on a 
surcharge. Similar consideration should be given for tax on tax situations and scenarios such as tax 
exceptions and bundling. 


2.1.1 Surcharge Types 

A surcharge type is used to classify surcharges into multiple categories. Multiple surcharge codes can 
be grouped under one surcharge type. This categorization helps in identifying and posting the 
individual surcharges to the right GL accounts and also used for contract exemptions. Contracts can 
be exempted from surcharge types, therefore all the surcharges under surcharge type are 
automatically exempted. The following examples are the main surcharge types currently supported 
by VRS. The system is not limited to the examples below: 

• LEGL - legal mandated surcharges, generally imposed by municipality at group, state, 
county, city, or district level 

• OPTL - optional surcharges 

• CONT - contract mandated surcharges 

• ARPT - airport fees 

• VREG - vehicle registration based surcharges 
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2.1.2 Exemptions 

Some customers are exempted from surcharges. There are three types of customer exemptions: 

• Local Exemptions - In some locations, rental branches do not charge the local customers 
(e.g., if the zip code of the driver is one of the exempted zip codes then the branch will not 
charge the customer). 

• Agreement/Contract Exemptions - This type of exemption is specified at the contract level 
and is applicable to a surcharge type rather than an individual surcharge, 

• Tax exemption flag through API - In addition to the above mentioned exemptions, the tax 
exemption flag that comes through API can also determine the applicability of surcharges. 
The exemption status is used to either include (N) or exempt (Y), but in the case of Canada it 
could have values like 'P (PST/QST exempt), 'G* (GST/HST exempt) and f B f (both). 

2.1.3 Surcharge Hierarchy 

Surcharge area hierarchy will be the basis for determining and calculating surcharges. Before 
defining the surcharges, a hierarchy of all the areas and branches is defined. In VRS both the tax and 
surcharge engines depend on a common hierarchy structure. Hierarchies are divided into four levels: 
state, county, city and district. To meet ERAC requirements for group level tax and surcharges, an 
area type of group will be added which will add a fifth level to the hierarchy. 


III Once the areas are defined, the branches can then be linked to the areas. Branches can be linked to 
p only one area and one area can have multiple branches. Once the complete area hierarchy is defined, 
j B y all the surcharges can then be defined and linked to the area code. Thus for a given branch, the 
system can find all the applicable surcharges from the surcharge hierarchy. 

2.1.4 Calculation Rules supported by Surcharge Engine 

When an application needs to assess the surcharges on a rental, it calls the surcharge engine via an 
API. Based on the input parameters provided, the surcharge engine then calculates the surcharges and 
sends the information back to the caller via an API. Surcharge engine is called for every product that 
can be surcharged. 

Surcharges are calculated using a calculation rule. A calculation rule is a combination of variables 
stored in a database table called CALC^RLS. Each example below shows the columns in 
CALCJRLS that are applicable to a particular calculation rule. A default value is provided for those 
columns that are defined as NOT NULL but do not apply to a calculation rule. We have intentionally 
left out those columns that are NULLABLE and are not applicable to the calculation rules, if these 
fields were to be populated the surcharge engine results may not reflect the intended surcharge 
calculation. 
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2.1.4.1 Percentage Based Rules 

Percentage based surcharges are applied to the product value. In order to assess correct rates, all the 
products that can be surcharged must be associated to the appropriate surcharges. 

2.1.4.1.1 Product Cost based with no rental duration limits 

This is one of the basic calculation rules. A percent rate applies to the product revenue. 


Rule ID 

Rule 
Value 

Rule 
Type 

Based 
On 

Charge Per 

Min 
Days 

Max 
Days 

Rule 
ID@Max 

Re-calc 

10% 

10 

% 

CVAL 

RNTL 

0 



N 


2.1.4.1.2 Product Cost based with rental duration limits. 

The surcharge assessed under this rule is calculated for a specified time limit. The surcharge is not 
assessed, if the vehicle is rented for more than 'n' number of days. 


Rule ID 

Rule 
Value 

Rule 
Type 

Based 
On 

Charge Per 

Min 
Days 

Max 
Days 

Rule 
ID@Max 

Re-calc 

10% 

10 

% 

CVAL 

RNTL 

0 

28 


N 


2.1.4.13 Vehicle Cost based 

The surcharge assessed under this rule is calculated on the basis of vehicle cost. If the cost of the 
rental vehicle falls in the specified range then the appropriate rate is applied, otherwise the focus 
switches to a new rule until appropriate match is found. In order to assess the surcharge accurately, a 
vehicle number must be passed to the Surcharge engine. If for some reason the vehicle cost or 
vehicle number is not available, the minimum rate is charged. 


Example - British Columbia, Canada locations: 


Rule ID 

Rule 
Value 

Rule 
Type 

Based 
On 

Charge Per 

Min 
Days 

Max 
Days 

Min. 
Charge 

Max 
Charge 

Rule 
ID@Max 

Re-calc 

BC7% 

7 

% 

VCST 

RNTL 

0 

0 

0 

31999 

BC8% 

Y 

BC8% 

8 

% 

VCST 

RNTL 

0 

0 

32000 

32999 

BC9% 

Y 

BC9% 

9 

% 

VCST 

RNTL 

0 

0 

33000 

33999 

BC10% 

Y 

BC10% 

10 

% 

VCST 

RNTL 

0 

0 

34000 



N 


2.1.4.2 Flat Rate Rules 

Flat rate surcharge is a fixed amount that is applied to only one product (e.g., time and mileage). 
When it comes to flat rate surcharges, the surcharge engine is 'currency neutral'. The $ symbol is used 
to indicate a flat rate surcharges. Mentioned below are examples of flat rate surcharges. 
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2.1.4.2.1 Per Rental Based 

This type of surcharge is charged only once, regardless of the rental duration. 


Example - Chicago: 


Rule ID 

Rule 

Rule 

Based 

Charge 

Min 

Re-calc 


Value 

Type 

On 

Per 

Days 


$2.00 

2.00 

$ 

NONE 

RNTL 

0 

N 


2.1.4.2.2 Per Rental Day based with no rental duration limits. 

This type of surcharge is assessed for every day the car is rented. The rental duration is based on the 
24-hour clock. 

Example: If a renter rents the car for more that 24 hours + grace period then the duration is 

H considered to be two days: 

«i 


Rule ID 

Rule 

Rule 

Based 

Charge Per 

Min 

Max 

Rule 

Re-calc 


Value 

Type 

On 


Days 

Days 

ID@Max 


$2.00D 

2.00 

$ 

NONE 

RDYS 

0 



N 


2.1.4.2.3 Per Rental Day based with rental duration limits. 

Ml. . 

^ This type of surcharge is assessed for every day the car is rented. The rental duration is based on the 
Jj j 24-hour clock. For example, if a renter rents the car for more that 24 hours + grace period then the 
111 duration is considered to be two days. If the rental duration exceeds the predefined range, then the 
i|i surcharge is assessed for the per day rate times maximum days. 

§1 

p Example - FL locations: 


Rule ID 

Rule 
Value 

Rule 
Type 

Based 
On 

Charge Per 

Min 
Days 

Max 
Days 

Rule 
ID<®Max 

Re-calc 

$2.05D 

2.05 

$ 

NONE 

RDYS 

0 

30 


N 


2.1.4.2.4 Per Calendar Day based with no rental duration limits. 

This type of surcharge is assessed for every calendar day the car is rented. 

Example - If the customer rents a car on Jan-1-2000 at 2300 hrs and returns on and it on Jan-2-2000 
at 0003 hrs then the surcharge will be assessed for 2 days: 


Rule ID 

Rule 

Rule 

Based 

Charge Per 

Min 

Max 

Rule 

Re-calc 


Value 

Type 

On 


Days 

Days 

ID@Max 


$1.00D 

1.00 

$ 

NONE 

CDYS 

0 



N 
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2.1.4.2.5 Per Calendar Day based with rental duration limits. 

This type of surcharge is assessed for every calendar day the car is rented. 

Example - If the customer rents a car on Jan-1-2000 at 2300 hrs and returns on and it on Jan-2-2000 
at 0003 hrs then the surcharge will be assessed for 2 days. In this type of a surcharge a rental duration 
range is specified. If the vehicle rental duration exceeds the range specified, the surcharge is assessed 
up to the maximum duration specified in the range: 


Rule ID 

Rule 

Rule 

Based 

Charge Per 

Min 

Max 

Rule 

Re-calc 


Value 

Type 

On 


Days 

Days 

ID@Max 


$1.00D 

1.00 

$ 

NONE 

CDYS 

0 

28 


N 


2.1.4.3 Vehicle Registration Based 

This type of surcharge is based on the actual registration cost of the vehicle. This type of surcharge is 
used to recoup the registration cost on a per day basis. The per day registration cost is l/365 th of the 
registration cost. In order to assess this surcharge, vehicle number must be present at the time of 
calculation. If for any reason a registration cost is not found, the surcharge engine will assess the 
maximum charge per day that is defined for the vehicle category rented. 


Example - California locations: 


Rule ID 

Rule 

Rule 

Based 

Charge Per 

Min 

Max 

Rule 

Re-calc 


Value 

Type 

On 


Days 

Days 

ID@Max 


$0VREG 

0.00 

$ 

VREG 

RDYS 

0 



N 


2.1.4.4 Vehicle Type Based 

This type of surcharge is based on type of the vehicle. It is assessed for all types of cars and trucks 
that are less the 3/4 of a ton in weight. In order to assess this surcharge, vehicle number must be 
present at the time of calculation. If for any reason weight value is not found, the surcharge engine 
will not assess any surcharge. Also if the rental duration exceeds f n f days, the surcharge will not be 
assessed. 


Rule ID 

Rule 
Value 

Rule 
Type 

Based 
On 

Charge Per 

Min 
Days 

Max 
Days 

Rule 
ID@Max 

Re-calc 

1.5D30 

1.50 

$ 

VTYP 

RDYS 

0 

28 

$0 

Y 

$0 

0.00 

% 

CVAL 

RNTL 

0 



N 


2.1.4.5 Switching from One Rate Type to Another 


This allows switching between calculation rules based on certain condition like exceeding the 
maximum number of days. Mentioned below are examples of these type of conditions. 

2.1.4.5.1 Percentage to Percentage 

In this type of surcharge, if the rental exceed the specified rental duration the surcharge engine 
switches to a new rule with a different percentage rate. 


Rule ID 1 Rule 1 Rule 1 Based [Charge Perl Min 1 Max 1 Rule I Re-calc 
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Value 

Type 

On 


Days 

Days 

ID@Max 


8% 

8.00 

% 

CVAL 

RNTL 

0 

30 

10% 

Y 

10% 

10.00 

% 

CVAL 

RNTL 

0 



N 


2.1.4.5.2 Percentage to Flat Rate 

In this type of surcharge if the rental exceeds a specified range, the surcharge engine switches to a 
new rule that is a flat rate. 


Rule ID 

Rule 
Value 

Rule 
Type 

Based 
On 

Charge Per 

Min 
Days 

Max 
Days 

Rule 
ID@Max 

Re-calc 

8% 

8.00 

% 

CVAL 

RNTL 

0 

30 

$2D 

Y 

$2D 

2.00 

$ 

NONE 

RDYS 

0 



N 


2.1.4.5.3 Flat Rate to Percentage 

!„: In this type of surcharge, if the rental exceeds a specified range, the surcharge engine switches to a 
j; I new rule that is a percentage rate. 


Rule ID 

Rule 

Rule 

Based 

Charge Per 

Min 

Max 

Rule 

Re-calc 


Value 

Type 

On 


Days 

Days 

ID@Max 


$2D30 

2.00 

$ 

NONE 

RDYS 

0 

30 

3% 

Y 

3% 

3.00 

% 

CVAL 

RNTL 

0 



N 


k 2.2 Detailed Design Description 

Is! •• 

111 

||I The surcharge engine is a collection of ! C f and Tro*C programs implemented in the form of a 

O Tuxedo service with an API. The API includes a generic "C function, TindSchgs' which handles the 

H Tuxedo specifics. 


The surcharge engine is a data driven service and relies on surcharge data maintained in a relational 
database to perform its functions (i.e., if no surcharges are set up 5 no surcharges can be assessed by 
the engine). For Enterprise, data maintenance will be done through front end user screens. 


Make 


Open 



Close 



Modify 

Reservation 


Ticket Process 


Ticket Process 


Ticket Process 







i 
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hi 
ar 

% 

hi 


Before a call is made to surcharge engine, surcharge related data is expected to have been set up and 
generally it is set up in the following order by the data reference team: 

Tax & surcharge hierarchy 
Surcharge calculation rules 
Surcharge types 
Surcharge codes 
Surcharges per charge types 
Exempted zip codes 

Exempted surcharges for exempted zip codes (local exemptions) 
Agreement/contract level surcharge exemptions 
Vehicle surcharge ranges 

Details are provided below for each gap identified during the gap analysis. The database and API 
changes for gaps addressed are highlighted in the subsequent sections. 


m 

m 
m 


fas 


k 
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2.2.1 Gap 20: Vehicle License Fee Cap 

Gap Description: 

This fee is designed to reimburse Enterprise for the VLF paid on a vehicle. It is calculated by taking 
the VLF paid for a specific unit and dividing it by 365 days. The VLF stops once the fee has been 
reimbursed to Enterprise. 

Solution: 

This involves changes to API as shown in the inputs section to pass actual VLF paid, accumulated 
VLF, and vehicle registration expiration date. In addition, a new column is being added to 
DVC JSTJSCHGS, where the minimum and maximum amounts are stored for reservation time 
quotation. The column, CAR CLS SUFX CDE will be added to properly reference the ERAC car 
class table (which has CARJXS_SUFX_CDE as a component of the primary key). 

Surcharge engine will be modified to determine if the annual VLF caps have been met or exceeded 
and thus not charge VLF. In order to identify the surcharges that belong to VLF type surcharges, a 
new base type code VCAF needs to be established and attached to the calculation rules that are set 
up and attached to surcharge codes. NOTE: After some additional analysis it was decided that 
the existing base type code 'VREG' can be used to meet this requirement This will reduce the 
amount of data ERAC will need to setup. 

For any reason, if vehicle specific data is not provided to the surcharge engine, then the surcharge 
engine returns minimum and maximum per day surcharge amounts based on the car class, group and 
the state code for check-out branch. These minimum and maximum values are maintained in the 
DVC_ST_SCHGS table. 

Pseudo code: 

If the surcharge is based on 1 VREG 1 then 

Copy the VLF related values from API 

If the VLF paid >0 and co_date < reg_exp_dt then 


VLF per day « VLF paid /Days in Year 
surcharge amt = VLF per day * charge__days 
If surcharge amt > (VLF paid - accumulated VLF) then 
surcharge amt - VLF paid - accumulated VLF 

else 

surcharge amt = surcharge amt 

End if 


End if 


End if 
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Y 



Calculate the surcharge 
amount from 
DVCJSTJSCHGS table 
using minimum per day amt 


1 

Y 

r 

Calculate the surcharge 
Amt as Charge Days * 
(VLF paid /Days in Year) 


r 


Assess the calculated 
surcharge amount 


■C 


Done 



Calculate the surcharge 
Amt as VLF paid - 
accumulated VLF 
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2.2.2 Gap 21: Ontario Fuel Tax requirements 

Gap Description: 

In Ontario, Canada, Enterprise needs to recoup pre-paid Fuel Tax with the surcharge that gets capped 
once the Fuel Tax has been fully recouped. The amount of charge is calculated as Fuel Tax paid 
divided by 180 days. 

Solution: 

Enterprise plans to prepay the Ontario Fuel Tax and recoup the expense with a flat per day surcharge. 
This method is currently supported in VRS and requires no change to the surcharge engine. At this 
time Enterprise does not want to cap this amount. Since VRS currently supports this requirement, 
there is no longer a gap to support Ontario Fuel Tax. 


2.2.3 Gap 22: Surcharges and Taxes need to support Transaction type 

Gap Description: 

Need the ability to exclude surcharges based on rental types. For example, a motor vehicle rental 
surcharge may be excluded from insurance replacement rentals. 

Solution: 

A new table, EXMPT__RNTL_SCHG^CDS, will be created to support this gap. (Please refer to the 
Database Impacts section for details on the table definition.) This new table will maintain all the 
excluded surcharge codes based on the rental type code. The surcharge engine code will be modified 
to look for any exceptions in this table before returning the applicable surcharges for each call. If 
there are any taxes that need to be excluded based on rental type, then they will be implemented as 
surcharges by setting up the tax data in the surcharge tables. 

2.2.4 Gap 23: Sales Tax Based on Vehicle Type 

Gap Description: 

In Illinois, Maine, and Maryland, sales taxes are calculated based on the type of vehicle being rented. 
For example, Maryland car rates are 11.5% and van rates are 8%. 

Solution: 

In the gap description, type of vehicle means the same thing as vehicle category or car class for 
Enterprise. Although this is a tax requirement, the solution involves accommodating it through the 
surcharge engine. To support this gap we need to change CALCJRLS table to add a new column 
called vehicle category (See DDL changes section 2.3 J A for database change). Since the client 
application captures vehicle category information at time of reservation, we will use vehicle category 
as the basis for calculating sales tax in Illinois, Maine, and Maryland. 
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• Change CALC_RLS table to add a new attribute VHCL_CAT_CD and 
CAR_CLS_SUFX_CDE to store car class code and its suffix. 

• Set up new rules with a base type of VCLS (for vehicle class) through data setup screens. 

• Change surcharge engine code to accommodate switching to different rules based on the input 
car class and calculate the correct surcharge amount. 

See the notes in Tax engine document regarding the data maintenance issues for taxes implemented 
as surcharges. 


An example with some sample data is shown below: 


Rule Id 

Rate &Type 

Calc Basis 

Charge Per 

Car Class 

Car Class 
Sufx Cd 

Switch to 
Rule 

R1 

11.5% 

VCLS 

RNTL 

ECAR 

01 

R2 

R2 

11.5% 

VCLS 

RNTL 

MCAR 

01 

R3 

R3 

10% 

VCLS 

RNTL 

PCAR 

01 

R4 

R4 

8.0% 

VCLS 

RNTL 

XVAR 

01 

R5 

R5 

7.5% 

VCLS 

RNTL 





2.2-5 Gap 25: Allow group level maintenance of Taxes & Surcharges 

Gap Description: 

Maintain the system on ar decentralized basis at the Corporate level ERAC has a decentralized 
structure (groups are typically separate legal entities). 

Solution: 

Group will be added as another level in the tax and surcharge hierarchy. This amounts to a new area 
type and a new column on the BILTASAREAS table. This will allow defining and maintaining 
surcharges at the group level as well as the other levels (state, county, city and district.) The 
surcharge engine then needs to be modified to query for surcharges at the group level in addition to 
the existing levels. Data base changes for this gap are shown in section 2.5 A A. 
Existing SQL query will be changed in the surcharge engine as shown below: 

SELECT 

all surcharge data 

all calculation rules data 

FROM 
WHERE 

AND SC.UDA_AREA_ID IN ( 

: bta_group_id , 

:bta_stpr_id, 
: bt account _id , 
:bta_city_id, 
:bta dist id ) 
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2.2.6 Gap 27: Accommodate detaching and reattaching of Branches in 
Hierarchy 

Gap Description: 

When branches physically change locations, the system needs to accommodate this move within the 
tax and surcharge hierarchy. In addition, the system must retrieve the appropriate surcharges, based 
on input date, for where the branch was at that time. 

Solution: 

Effective start and end dates will be added to BIL JTAS_AREAS and STN CNTR to track, over 
time, where a branch resides within the hierarchy. The surcharge engine will be modified to use 
open ticket date in its query of BIL JTAS_ARE AS to get the appropriate surcharges for a given 
branch at that point in time. This assumes that the maintenance screens will populate these dates 
ensuring that, for a given branch, there are no overlapping dates in the BIL JTAS__AREAS table. 

The surcharge engine code will be modified to fetch area hierarchy using effective dates as follows: 

DECLARE 

bil_tas_area_curs CURSOR FOR 

SELECT 

TAS.GROUPJED, 

TAS.STPR_ID, 
TAS.COUN_ID, 
TAS.CITY_ID, 
TAS.DIST ID 


GWYDB.BIL TAS AREAS TAS 


FROM 
WHERE 

TAS . CRY__ARIMP_CRY_CD = : bt a_cry_arimp_cry_cd 
AND TAS . STN_STN_ID = :bta_stn_stn_id 

AND TAS . SCNTR_STN_CNTR_ID = :bta_scntr_stn_cntr_id 
AND TRUNC( TOJDATE { :s_co_date, * YYYYMMDDHH2 4MX 1 ) ) 
BETWEEN 

TAS . EFF__DT 

AND NVL( TAS.STOP_DT, TO__DATE ( : g_endjd"t , 'DD-MON-YYYY HH24 :MI : SS T ) ) 

This change will ensure that only the hierarchy that was in effect for the branch at the time of open 
ticket would be used to retrieve surcharges applicable. 
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2.2.7 Gap 29: Need the ability to track all changes to Surcharge & Tax data 

Gap Description: 

Enterprise has standard audit columns they use on all tables to track change history. We need to add 
these columns to several of the tables being ported from the VRS data model to the Enterprise data 
model 

Solution: 

Four columns will be added to each of the tax and surcharge tables. 

1. Create Date & Time stamp 

2. Create User Id 

3. Last update Date & Time stamp 

4. Last update user Id 

Any process, which updates these tables, needs to update these columns. This does not impact the 
surcharge engine directly as it does not update any tables. See the DDL changes section for actual 
table changes proposed. 

2.2.8 Gap 31: Provide minimum and maximum vehicle license fee per day 

Gap Description: 

System must provide both minimum and maximum daily vehicle license fee surcharge amounts. 
Solution: 

Currently in VRS, both minimum and maximum values are maintained, but only the maximum is 
returned. The code will be modified to return both the minimum and maximum surcharge 
parameters. Both elements already exist in the output parameter list. 

In VRS, if the specific vehicle unit number is not provided, the surcharge engine will calculate 
surcharge amount based on the maximum per day amount from the DVC ST SCHGS table. If the 
unit number is provided but VLF amounts are not passed via API, then surcharge is calculated based 
on minimum per day VLF amount from the table. 

The logic and format the surcharge engine uses in returning the vehicle license fees has changed. 
Instead of returning these values through existing output parameters as one line item, the surcharge 
engine will be changed as follows: 
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• At reservation time, when a specific vehicle is not attached to the rental, return both 
minimum and maximum per day license fee amounts as two separate line items from the 
surcharge engine. Both will have the activity flag set to 'NS* to indicate to the charge engine 
not to include these items in the calculation of rental charges. The minimum per day amount 
will be copied into the surcharge rate for one line item and the maximum per day amount for 
the other. Both line items will have the same surcharge id. 

• At rental time, when a specific vehicle is attached to the rental but no license fee details are 
available, return only one line item from the surcharge engine for the license fee surcharge, 
using minimum per day amount to calculate the actual surcharge amount. In this case, the 
activity flag will be set to 'AS' to indicate to the charge engine to include this item in the 
calculation of rental charges. 

2.2.9 Gap 141: Surcharges & Taxes based on Registration for North and South 
Carolina vehicles 


Gap Description: 

This gap concerns the Motor Vehicle Highway Tax (MVHT) which some states have. Some states 
give the option of either prepaying this tax at vehicle purchase time or collecting the tax as the 
vehicle is rented and remitting the tax to the government. Currently Enterprise uses the first method 
only in North Carolina. That is, as vehicles are purchased in North Carolina, the MVHT is prepaid to 
the government. Enterprise recoups this money using a surcharge as these vehicles are rented. 
However, non-NC vehicles are also rented in NC. These vehicles have not had the NC MVHT 
prepaid, but the tax is still applicable. For these rentals, the tax must be charged and remitted to the 
government. So both the tax and the surcharge must be set up, but only one should ever be applied. 
This situation could arise for other states as well if Enterprise chooses to use the prepay option in 
other states that offer it. 

Special consideration must be given when vehicle owning state is unknown. This can occur, for 
example, with "Z units" (vehicles not fully installed and lacking in registration details.) Enterprise 
needs the capability to specify, through data set up, whether the tax or surcharge should be applied in 
these cases. 
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Solution: 

A new attribute, state code, will be added to the calculation rules table. Both the surcharge and the 
tax will get set up as surcharges {resulting in two rows in the schg_cds table) and will utilize two 
new calculation rules. These new calculation rules would use new base type values, such as 4 STSC 
and 'STTX\ to attach to the surcharge and tax respectively. These rules would also utilize the new 
state column to determine the state in which the MVHT has been prepaid. Vehicle owning state is 
one of the surcharge engine inputs. The surcharge engine will compare the vehicle owning state (via 
the API) to the state code of these rules to determine which to apply. If the owning state passed in is 
unknown (blank) the "Re-calc" field will be used to determine which to apply, the tax or the 
surcharge. If this field is blank or 6 N' then the surcharge will be applied. If the field is 6 Y' the tax 
will apply. Following are four examples showing various possibilities: 

(Note: The first table in each example shows the surcharge and tax setup in the schg_cds table. A 
separate surcharge code for each allows for distinct naming and reporting to the general ledger. The 
second table depicts the data as setup in the calc_rls table.) 

Example 1 : Here if the vehicle owning state is either unknown or 'NC\ then the surcharge will be 
assessed; otherwise the tax will be assessed. 


SCHG 

CDS 

Schg Id 

Eff_Dt 

Dsply_Ln1 

Rule Id 

Schg_Typ 

141S01 

01/01/01 

NC MVHT surcharge 

1 

LEGL 

141S02 

01/01/01 

NC MVHT tax 

2 

STAX 

CALC RLS 


Rule ID 

Rule 

Rule 

Based 

Charge 

State 

Re-calc 


Value 

Type 

On 

Per 

Code 


1 

2.00 

$ 

STSC 

RDYS 

NC 

N 

2 

4 

% 

STTX 

RNTL 

NC 

N 


Example 2: In this example, for Nevada, the surcharge gets assessed only if the vehicle owning state 
is fi NV\ If it is unknown or some other state, the tax gets assessed. 

SCHG CDS 


Schgjd 

EffJDt 

DsplyJLnl 

Rulejd 

Schg_Typ 

141S03 

01/01/01 

NV MVHT surcharge 

3 

LEGL 

141S04 

01/01/01 

NV MVHT tax 

4 

STAX 

CALC 

RLS 


Rule ID 

Rule 
Value 

Rule 
Type 

Based 
On 

Charge 
Per 

State 
Code 

Re-calc 

3 

2.00 

$ 

STSC 

RDYS 

NV 

Y 

4 

4 

% 

STTX 

RNTL 

NV 

Y 


Last Save Date: 1 1/6/200 1 9:09 AM 


Page 20 of 38 


Surcharge Engine Detail Design_I3 (2) 


rent-a-car 


ECARS v2.0 - Accurate Out the Door Pricing 
Detailed Design Specification 


perotsystems TO 


It is important at this point to note that the "Re-calc" field should be set the same for both the tax and 
the surcharge in a given state. The engine will use that value to determine what to apply in the event 
the vehicle owning state is not known. The next two examples show the ambiguity that arises when 
these flags are not the same and indicates how the engine will handle it. The logic is detailed in the 
pseudo code that follows the examples. 

Example 3 : In this example, now for Maryland, everything is still fine except in the event of an 
unknown vehicle owning state. The "Re-calc" value has been set up ambiguously; the empty value 
on the surcharge line indicates it is the default, but the 4 Y 5 on the tax line indicates it is the default. 
In this case, the engine will assess whichever one it encounters first. It will not assess both, but 
simply ignore whichever is second. 


SCHG CDS 


Schgjd 

Eff Dt 

Dsply_Ln1 

Rule id 

Schg Typ 

141S05 

01/01/01 

MD MVHT surcharge 

5 

LEGL 

141S06 

01/01/01 

MD MVHT tax 

6 

STAX 

CALC 

RLS 


Rule ID 

Rule 

Rule 

Based 

Charge 

State 

Re-calc 


Value 

Type 

On 

Per 

Code 


5 

2.00 

$ 

STSC 

RDYS 

MD 

N 

6 

4 

% 

STTX 

RNTL 

MD 

Y 


Example 4: In this Pennsylvania example, as with #3, everything is still fine except in the event of 
an unknown vehicle owning state. The "Re-calc" value is ambiguous here in precisely the opposite 
way as example 3. Here both lines are indicating that the other should be assessed when vehicle 
owning state is unknown. In this case neither the tax nor surcharge will be assessed. 

SCHG CDS 


Schgjd 

Eff Dt 

Dsply_Ln1 

Rule Id 

Schg_Typ 

141S07 

01/01/01 

PA MVHT surcharge 

7 

LEGL 

141S08 

01/01/01 

PA MVHT tax 

8 

STAX 

CALC RLS 


Rule ID 

Rule 
Value 

Rule 
Type 

Based 
On 

Charge 
Per 

State 
Code 

Re-calc 


7 

2.00 

$ 

STSC 

RDYS 

PA 

Y 

8 

4 

% 

STTX 

RNTL 

PA 

N 


Notes: 

To support this solution, the front-end screens must allow maintenance to the Re-calc field when a 
calc rule with base type 4 STSC 5 or 6 STTX 5 is being set up. This is the mechanism by which a user 
can indicate which to apply in the event of an unknown vehicle owning state. 
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Examples 3 and 4 represent ambiguous data situations and seem hardly ideal. The front-end screens 
could possibly control this if desired. Other business rules could also be defined, such as "Always 
default the surcharge in these cases". The assumptions used here are that you should never assess 
both the tax and the surcharge (example 3) and assessing neither is OK (example 4). 

Pseudo code: 

IF base type = 'STSC 

IF vehicle owning state unknown 
IFrecalc = 'Y' 

Do not assess the schg 

ELSE 

IF tax already assessed 

Do not assess the schg 

Userlog a message for conflicting data 

ELSE 

Assess the schg 

ENDIF 

ENDIF 

ELSE 

IF vehicle owning state = calc rule state 
Assess the schg 

ELSE 

Do not assess the schg 

ENDIF 


L ENDIF 


ENDIF 


IF base type = 'STTX' 
:| * '■ IF vehicle owning state unknown 

. IF recalc « ' Y' 

IF schg already assessed 

Do not assess the tax 
Userlog a message for conflicting data 

ELSE 

Assess the tax 

ENDIF 

ELSE 

Do not assess the tax 

ENDIF 

ELSE 

IF vehicle owning state = calc rule state 
Do not assess the tax 

ELSE 

Assess the tax 

ENDIF 

ENDIF 

ENDIF 
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Flow Chart: 
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2.3 Database Table Impacts 

To calculate applicable surcharges for a given charge type, the surcharge engine uses a set of 
database tables to obtain all necessary information pertaining to surcharge hierarchy definitions for 
each branch, applicable surcharges in the given area, calculation rules etc. Please refer to Appendix B 
for an entity relationship diagram of the data model used by the surcharge engine. 

This following sections outline the DDL changes that are required to address all the gaps in this 
document. Changes are indicated by highlighted text. 

2.3.1.1 BILJTAS_AREAS Table 

This table stores all the hierarchy information in the form of a flat line for every branch that would 
have surcharges to be calculated. This table is being changed to address gaps 25 and 27 mentioned in 
'Gaps Addressed Summary' section at the top this document. 


Columns: 



Primary Kev: 


STN_STN_ID, SCNTR_STN_CNTR_ID, feft/T ASi^^lWlBP 
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2.3.1.2 STN_CNTR Table 

This table associates a given station to the user defined area to which it belongs. 


Columns: 


STNJSTNJD 

STN_CNTR_ID 

STN_CNTR_NM 

UDA_AREAJD 

UDA_ATY__AREA_TYP 

|TO L CNtR^ItbTE 


J0PDATE BYf; i ' -\^yr:< 


NOT NULL 
NOT NULL 
NOT NULL 
NULL 
NULL 

;notnull- 

null- 7 -,. : ; 


VARCHAR2(10) 

VARCHAR2(1) 

VARCHAR2(30) 

YARCHAR2{I0) 

VARCHAR2(10) 

^date 


14*..' fi^y^i. 


>NUEL 


a 

! Primary Key: 

j: STO_STN_ID, STN_CNTR__ID 5 Sm^m^fi^-fcK 

j 2.3.1.3 SCHGL.CDS table 

, This table is used to maintain surcharges for different areas that are defined in the taxes and 

■I surcharge hierarchy. 


Columns: 


SCHGJD 
EFF_DT 

CRY_AMMP_CRY_CD 
EXMPTJND 

PRNT_EXMPT_MSG_FLG 

R>ITL_CAP_AMT 

SCHG_NAM 

SCHG_SEQ 

SCTYP_SCHG_TYP 

SUSPJND 

UDA_AREA_ID 

UDA_ATY_AREA_TYP 

YRLY_CAP_AMT 

CRLS_RULE_ID 

DSPLY_LN1 

DSPLY_LN2 

EXMPTJvlSG 

GLT_SEQ 

kECORTKSTATUS " 

- -.v.-" * • "V 
CREAIE^TlMstAMP' *. 
b^ATCJvlODliE 
UPDATE miESTAkp: /\ : 
otdatcIby > ,i 

UPDATEJviODULE 
RATE DESC 


NOT NULL 
NOT NULL 
NOT NULL 
NOT NULL 
NOT NULL 
NOT NULL 
NULL 
NOT NULL 
NOT NULL 
NOT NULL 
NOT NULL 
NOT NULL 
NOT NULL 
NULL 
NULL 
NULL 
NULL 
NULL 


VARCHAR2(15) 
DATE 

VARCHAR2(2) 

VARCHAR2(I) 

VARCHAR2(1) 

NUMBER(15 5 2) 

VARCHAR2(35) 

NUMBER(3) 

VARCHAR2(4) 

VARCHAR2(i) 



NfULL v ' 
NULL 


VARCHAR2(10) 
NUMBER(15,2) 
VARCHAR2(6) 
VARCHAR2(35) 
VARCHAR2(35) 
VARCHAR2(35) 
NUMBER(6) 
;\¥ARdHM2(2) 

r BATE 

: VMC2IAR2(1G24) 

/VA^HAR2(3G) 
. VAROLfll2(I024) 
VARCHAR2(4) 
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RCT_CHG__TYP 

SCHGJJSR_NOTES 

STOP_DT 

YTD_SCHG_AMT 

WALKIN_EXMPT_FLG 

RNTL_MIN_AMT 

2.3.1.4 CALC RLS Table 


NULL 

NULL 

NULL 

NULL 

NOT NULL 

NULL 


VARCHAR2(5) 

VARCHAR2(100) 

DATE 

NUMBER(15,3) 
VARCHAR2(1) 
NUMBER(15,2) 


This table is used to define rules for calculating surcharges. A surcharge id is always associated to a 
calculation rule. One calculation rule may be applied to multiple surcharges. Rate is part of the 
calculation rule. 


Columns: 

RULEJD 

BASEJTYPE 

MINUOB_VAL 

RECALC_ON_MAX 

RULEJTYPE 

RULEJVAL 

UNITJ)F_CHRG 

KEEPJPCT 

MAXCHRGVAL 

MAX_UOB_VAL 

MIN_CHRG_VAL 

REIMBJPCT 

RULE_ID_AT_MAX 

UNIT OF_BASE 


NOT NULL 
NOT NULL 
NOT NULL 
NOT NULL 
NOT NULL 
NOT NULL 
NOT NULL 
NULL 
NULL 
NULL 
NULL 
NULL 
NULL 
NULL 


VARCHAR2(6) 
VARCHAR2(4) 
NUMBER(15,3) 
VARCHAR2(1) 
VARCHAR2(4) 
NUMBER(15,3) 
VARCHAR2(4) 
NUMBER(5,2) 
NUMBER(15,3) 
NUMBER(15 5 3) 
NUMBER(15,3) 
NUMBER(5 ? 2) 
VARCHAR2(6) 
VARCHAR2(4) 



CNTRYJSO^CDE NULL 
CNTRY SUBDIV SHRT NAM NULL 


VARCHAR2(6) 
VARCHAR2(12) 


2.3.1.5 SCHGJTHGJTYPS Table 

This table stores all surcharge codes that are associated with each charge type 


Columns: 


SCHGJEFFJDT 

RCT_CHG_TYP 

LINE_NBR 

INCL_BASE_AMT 

SCHGJ)NLINE 

SCHG_SCHGJD 

SEQ_NBR 

RECORDJSTATUS . 

cr£ate_by ; - > - 

€REAT£ TTMESTAMP 


NOT NULL 
NOT NULL 
NOT NULL 
NOT NULL 
NOT NULL 
NOT NULL 
NOT NULL 
NULL - 
: NOT NULL 

null ;7 


DATE 

VARCHAR2(5) 
NUMBER(2) 
VARCHAR2(1) 
NUMBER(2) 
VARCHAR2(15) 
NUMBER(3) 
VARGHAR2(2) 
:;,VARGHAR2(30) 
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PiEATE_MODULE / : \ : \ ' ^ NULL s'v^w- ^;V^C3L«l2{i024) 

IWDAITEBY ■ *'VC : : NUI^- ? ^:^W^HAR2(30) 
UPDATE JtfODULE , v NULL , V^E^K2(1024) 

2.3.1.6 SCHG_TYPS Table 

This table is used to store surcharge types. A surcharge type is used to classify surcharges into 
multiple categories. Multiple surcharge ID ! s can be grouped under one surcharge type. 

Columns: 

SCHGJTYP NOT NULL VARCHAR2(4) 

RCT_CHG_TYP NOT NULL VARCHAR2(5) 

OPTNJND NULL VARCHAR2(1) 

SCHGJTYPJDESC NULL VARCHAR2(35) 



2.3.1.7 DVCJSTJSCHGS Table 

This table is used to maintain minimum and maximum surcharges for vehicle categories for a state. 
The surcharge range can be applicable for a given range of dates. This information will be used for 
assessing surcharges ONLY IF the vehicle unit number is not available at the time of assessment. 
Adding Group to this table is a new functionality to support Enterprise needs. 

Columns: 

DVCJ:RY_ARIMP_CRY_CD NOT NULL VARCHAR2(2) 


DVC_VCA_CAT_CD NOT NULL 

CAR_CLSJSUFX_CDE NOT NULL VARCHAR2(4) 

ST_STATE_CD NOT NULL VARCHAR2(6) 

STRT.DT NOT NULL DATE 

MAX_SCHG_AMT NOT NULL NUMBER(15,3) 

MIN_SCHG_AMT NOT NULL NUMBER(1 5,3) 


EXPR DT NULL DATE 
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23.1.8 CONSCHGJTYPS Table 


This table will be used for defining contract exemptions. Contracts will be exempted from surcharge 
surcharge types. All the surcharges that fall under the surcharge types will be exempted. 

Columns: 

CONCONJD NOT NULL NUMBER(8) 

SCTYPJSCHG_TYP NOT NULL VARCHAR2(4) 

EFF_DT NOT NULL DATE 

END_DT NULL DATE 

RECCmKSTAtUS' > ; " - \ \ * • $UIL; V ' V ' K VARCHAR2(2) 

PPDATBJBY: ; o 

OPDATEMODULE- >' ;'\.V/Vt: r:;iirtt:.i^cMsd^^^ 


'O. 2.3.1.9 SCHGJEXMPT^CDS Table 

|t| ■ 

pi. This table is used to associate surcharges to the exempted ZIP codes. If a renters ZIP code matches 
any of the exempted ZIP codes, then the renter will automatically be exempted from the surcharges 
? J that are linked to the ZIP code. 


U Columns: 

l r SCHG_SCHGJD NOT NULL VARCHAR2(15) 

Hi SCHGEFFJDT NOT NULL DATE 

ill EZCJZIPCD NOT NULL NUMBER(9) 

ill l^^yrA^::^^ v ■ : c-*^t;^ 

ijroATE^r^ 5 S'^\v:^^g 

2.3.1.10 EXMPT^ZIP^CDS Table 


This table maintains all the ZIP codes that are eligible for surcharge exemptions. Exemptions related 
to ZIP code are also called as local exemptions. 


Columns: 

ZIP_CD NOT NULL NUMBER(9) 

EZCDESC NOT NULL VARCHAR2(35) 

3OTDAtE^BY\ \ v \- , ' "iRH^^ 

UPDATE JdODULE ; , / vNUIX \ 5 : \ V^OlAR2(1024) 
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2.3.1.11 XMPTJRENTJSCHG Table 

This is a new table added to the data model to support Enterprise needs. This table maintains all the exempted surcharge 
codes based on rental type code. 


Columns: 


SCHG ID V 


' V^OtBlJLt " VVARCHAK2(15) 
EFFJ3TE ; \ ^ r:",^'." ^ '"j ^iJWTWla^ ^'iWfflB" 
XMPT_SCHG_^RJDTE . ' : \/^\:^ Z'M&£ * ■ V;"- ^<I>KfE 
RENT TYP CDE " ; .UV; HOI^L v > MJMBERr6) 


RENT_TYP CDE 
RECORD 



Primary Key: 
1 Foreign Key: 



2.3.1.12 AREA RLTNS 


This table holds the parent/child relationships between area ids. 


Columns: 


UDA_ATY_AREAJTYPJ > RNT 
UDA_ATY_AREA_TYP_CHLD 
UDA_AREAJDJPRNT 
UDA AREAJD_CHLD 
RECORD STATUS/ Sy^*^. 


NOT NULL 
NOT NULL 
NOT NULL 
NOT NULL 


VARCHAR2(10) 
VARCHAR2(10) 



2.3.1.13 AREA TYPS 


This table holds the valid area types for area ids with descriptions of each. 


Columns: 


AREA_TYP 
AREA_TYP_ACT 
AREAJTYP_DESC 
AREA_TYP_SHRT_DESC 
HIERARCHY JLVL 
DATES JREQJLG 
RECORIXSTATUS \ ' . [■ : 

CreatejbY' - 

CREATE TIMESTAMP / 


NOT NULL 
NOT NULL 
NULL 
NULL 
NULL 
NULL 
NULL .,: . 
NOT NULL 7 

null V ; 


VARCHAR2(10) 
VARCHAR2(3) 
VARCHAR2(35) 
VARCHAR2(10) 
NUMBER(2) 
VARCHAR2(1) 
; : :yARCHAR2(2) 
VAR€HAR2(30) 
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CREATEJMODULE : 
tlPDAITE^TIMESTAiMP 
UPDATEJ3Y .. ; 
UPDATE MODULE 


NULL 
;NULL 
NULL 
NULL 


;VARCHAR2{1024) 
BATE 

VARCHAR2(30) 
VARCHAR2(1024) 


2.4 Inputs 

The surcharge engine is a Tuxedo based server that services request from the caller. Surcharge API 
will process the requests from the callers and pass the requests to the engine and then present 
surcharges and descriptions to caller applications. The input buffer is defined below with items under 
the FML field name column shown in BOLD are added to address gaps. 



Standard Header 


The content of this header 
will be used for debugging, 
user test support, 
performance monitoring, 
tuning and error logging 


Refer to standard header 
document for layout and 
population rules 


Yes 


All Clients 


view version 


co^crycd 


View Version string 


FN VIEW VERSION 


Yes 


string 


100 


Tux View 


Pick-up country code 


FN SCHG CO COUNTRY CD Yes 


string 


Client App 


co date 


Pick up date stamp 


FN SCHG CO TIMESTAMP 


Yes 


string 


13 


Client App 


ci date 


Return date stamp 


FN SCHG CI TIMESTAMP 


Yes 


string 


13 


Client App 


co stn 


Pick-up branch Id 


FN SCHG CO STN ID 


Yes 


string 


Client App 


cp^s&qrcd 


State; code fofPick^up 
braaith 


Yes 


3 


Client App 


chg typ 


Charge/ product type 


FN SCHG CHG TYP 


Yes 


string 


Client App 


chgamt 


Charge amount 


FN SCHG AMT 


Yes 


double 


Client App 


vhcl cat cd 


Vehicle category 


FN SCHG CAT CD 


Yes 


string 


Client App 


vhcl unit nbr 


vhcl own st 


Vehicle unit number 


FN SCHG VHCL UNIT NBR 


No 


Vehicle registration state 


long 


FN_SCHGjraCLJ3WSTAT 
E 


No 


string 


Client App 


Client App 


zip_cd 


Zip code of renter - 
required for some local 
exemptions 


FN SCHG ZIP CD 


No 


long 


4 


Client App 


tx exmpt flag 
con id 


Tax exemption flag 


FN SCHG EXEMPT FLAG 


No 


char 


Client App 


Contract Id with customer 


FN SCHG CON ID 


No 


long 


Client App 


rntl days 


Total duration in days 


FN SCHG RNTL DAYS 


Yes 


long 


Client App 


basedays 


Base days 


FN SCHG BASE DAYS 


No 


long 


Client App 


extra_days 


Extra days 


FN SCHG EXTRA DAYS 


No 


long 


Client App 


extension days 


Extension days 


FN SCHG EXTENSION DAYS 


No 


Jon£_ 


Client App 


counter id 


Counter Id of the Branch 


FN SCHG COUNTER ID 


Yes 


char 


Client App 


walkinjlg 


Walk-in Rental indicator, 
(Y=Walk-m,N=Fly-in) 


FN SCHG WALKIN FLG 


No 


char 


Client App 


waive__arpt_fee_fl 
g 


Y/N=Charge/Don't charge 
airport concession fee 


FN_SCHG_WAIVE__ARPT_FEE 
FLG 


No 


char 


Client App 


vhcl weight 


Vehicle Wt in tons 


m SCHG VHCL WT 


No 


double 


8 


Client App 


price 


Vehicle Price 


EN SCHG VHCL TPRICE 


No 


double 


8 


Client App 


total annual VLF 


Vehicle Reg cost/license 


FN SCHG VLF CST 


No 


double 


8 


Client App 


Last Save Date: 1 3/6/2001 9:09 AM 


Page 30 of 38 


Surcharge Engine Detail Design_I3 (2) 


ECARS v2.0 - Accurate Out the Door Pricing 
Detailed Design Specification 


pcfotsystems" 


Surcharge Enwei 


Wife 


Uescrtptiott 







fee paid 






Ylfeeg^xpjit 

Vehicle registration exnirV 
date 




Q 

^Henriipp 

yhcljiype 

Vehicle Tvpe CR=Car 
TR=f ruck 

FN SCHG VHGL TYPE 

No 



Viieui /vpp 

vhclj:eg_ciy 

VeMcIe registration 
country 


No 

string 

3 

Client App 


Accumulated vehicle 
license fee 

i . .1 ' .. ' 


No 

double 

8 

Client App 

\foelvengine size 

Vehicle En#ie size 

FN ;S£H(S iyPHC^®© SIZE 

No 

double 

8 

Client App 

car bis sufx cde 

Vehicfe class suffix 


No 

String 

5 

Client App 

r^nt_£typ_cde 

RA^l^e^cM^\^4^3i 
i),;S^or:i^e^&Me^ea 

^ein^^dMs * ' " 


Yes 

Char 

1 

Client App 


2.5 Outputs 

The surcharge engine inserts all applicable surcharge details into the Tuxedo output buffer and 
returns to the caller process. The calculated surcharge items will not be directly recorded into the 
database by the surcharge engine. It is the calling processes' responsibility to manage the database 
transaction - the surcharge engine does no commits or rollbacks. The output buffer is defined below. 
The items under the "FML field name" column in BOLD are added to the output to address gaps for 
Enterprise project 



Aft.'' - ..-■» ?.\>r-M. 


Output Parameter 

Description ' ? ] 





err cd 

Error Code 

FN SCHG ERR CD 

long 

4 

SE 

err msg[361 

Error message 

FN SCHG ERR MSG 

char 

81 

SE 

Num schgs 

Number of surcharges returned 

FN SCHG NUM SCHGS 

long 

4 

SE 

Schg id[64][16] 

Surcharge Identifiers 

FN SCHG SCHG ID 

char 

16 

SE 

eff_dt[64][13] 

Effective date for each surcharge 

FN SCHG EFF DT 

char 

13 

SE 

Schg basis[64] 

Base amount used for Calculating 

FN SCHG SCHG BASIS 

double 

8 

SE 

Schg rate[64] 

Surcharge Rate applied to product 

FN SCHG SCHG RT 

double 

8 

SE 

Schgjratejype[64] 

Rate type - Rental, Daily, Percent 
(actual values $ Or %) 

FN_SCHG_SCHG_RT_TYPE 

char 

1 

SE 

Schg amt[64] 

Surcharge Amount 

FN SCHG SCHG AMT 

double 

8 

SE 

Chg unit[64] 

Surcharge units charged 

FN SCHG CHG UNIT 

long 

4 

SE 

dsply lnl[641[36] 

Surcharge Display line 1 

FN SCHG DSPLY LN1 

char 

36 

SE 

dsply ln2[641F361 

Surcharge Display line 2 

FN SCHG DSPLY LN2 

char 

36 

SE 

git seq[64] 

GL code to be used for posting 

FN SCHG GLT SEQ 

long 

4 

SE 

Min_vhcl_schg[64] 

Minimum vehicle surcharge per 
day 

FN_SCHG_MIN_VHCL_SCHG 

double 

8 

SE 

Max_vhcl_schg[64] 

Maximum vehicle surcharge per 
day 

FN_SCHG_MAX_VHCL_SCHG 

double 

8 

SE 

exmpt msg[64][36] 

Exemption message 

FN SCHG EXMPT MSG 

char 

36 

SE 
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ret chg typr641f6] 

Surcharge type code 

FN SCHG RCT CHG TYP ' 

char 

6 

SE 

act_flg[64][3] 

Charge activity code AS=DispIay, 
NN=No Display 

FNSCHGACTFLG 

char 

3 

SE 

parentjndex[64] 

Is this a surcharge on another 
surcharge? = -1 otherwise 

FN_SCHG_PARENT_INDEX 

long 

4 

SE 

lncl_chg_basis[64] 

Product base amount included for 
calculating surcharge (Y/N) 

FN_SCHG_INCL_CHG_BASIS 

char 

1 

SE 

sctyp> schg typ[64][ 

Surcharge Type 5 OPTL, LEGL 

FN_SCHG_SCTYP_SCHG_TYP 

char 

5 

SE 

5] 

etc., 





rati min amt 

Minimum surcharge per rental 

FN ■ SGHG -RNTL MIN AMT 

double 

8 

SE 


h. 

IS? 

m 


is? * 

ill 


Sample Input/Output from Surcharge Engine 

The following is an example of output produced by the surcharge engine for a given set of input 
values: 


INPUTS 

Country Code 

US 

Checkout Date 

200105200000 

Checkin Date 

200105260000 

Branch ID 

STLT01 

Charge Type 

00001 

Charge Amount 

100.000 

VhcL Cat. Code 

FCAR 

Vhcl.Unit# 

1587021 

Vhcl. Own State 

MN 

Renter Zip Cd 

0 

Tax Exempt 

N 

Contract ID 

0 

Rental Days 

3 

Base Days 

0 

Extra Days 

0 

Extension Days 

0 

Counter Id 

1 

WalkinFlag 


Waive Arpt Fee 

N 
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OUTPUTS 

ERR CD 

0 

0 

ERR MSG 



NUM SCHGS 

2 

2 

SCHG ID 

US4STARP1 

US4STARP2 

EFFDT 

19980707 

20000802 

STYP 

OPTL 

VREG 

BASIS 

100.000 

110.000 

RATE 

10.000 

2.500 

RATE TYPE 

c 

C 

SCHGAMT 

10.000 

2.750 

ACTIVITY FLAG 

AS 

AS 

CHGUNT 

1 

1 

DISPLYLN1 

CONCESSION 

REGISTRATION 


RECOUPMENT FEE 

RECOUP FEE 2.50 


10PCT 

PCT 

DISPLYLN2 



MEN VHCL SCHG 



MAX VHCL SCHG 



GLT SEQ 

445 

745 

CHGTYP 

00025 

00074 

PARENT INDEX 

-1 

0 

INC CHG BASIS 

N 

Y 

EXEMPT MSG 
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2.6 Detailed Process Flow 

The following picture illustrates the high level view of surcharge engine. 


Client 


e.g. Charge engine 


Surcharge Engine Tuxedo server 


FindSchgs 


C interface to the 
Surcharge engine 


BILTC0420A 
SvcCall 


C/Tuxedo translation 


BILTS0420A 


Surcharge engine 
service 


BILTS0420A_SvcData 
Access 


Main logic for surcharges 


A given client typically calls the surcharge engine via 
the "wrapper" C function, FindSchgss. This in turn 
calls BILTC0420A_SvcCall which handles translation of 
C variables into corresponding FML buffers. It also 
makes the actual call to the engine itself The engine 
retrieves and computes surcharges which are returned 
through the same path back to the calling client 


Database 



Data 


Maintenance 


User maintained 


I—I 


<— 


screens 


For surcharge engine service the whole logic is defined 
in DataAccess module. The data maintenance for 
surcharge engine occurs via online screens. 


Each of the main components of the surcharge engine depicted above is discussed below. 
FindSchgs: 

This function will initiate a call to the surcharge service for a given branch and charge type. The 
surcharge service will return all applicable surcharges in a structure. FindSchgs itself is a pure C 
function and is called as such. All the Tuxedo specifics are managed by FindSchgs and the follow on 
routines it calls. This insulates client developers from the need to have specific knowledge about 
Tuxedo. As far as clients are concerned, this function is the API to the surcharge engine. The inputs 
and outputs of this function are given in the inputs and outputs sections of this document. 
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BILTC0420AJSvcCaIl: 

This function handles manipulation of 'C variables into Tuxedo buffers and makes the actual 
Tuxedo call to the surcharge engine. Outputs from the engine are converted back to typical C 
variables and returned. Use of this function by FindSchgs frees clients from any need for Tuxedo 
expertise or manipulation. 

BILTS0420A: 

This is the actual entry point to the surcharge engine. It takes the FML32 buffer data it was passed 
and converts this back to VIEW32 format in order to pass the inputs to the database access module in 
more "C like" fashion. It then makes the call to the data base access module using the VIEW32 
buffers. Upon return, it converts the VIEW32 output buffer to an FML32 buffer and issues a 
tpreturn. 

BILTS042OAJ>ataAccess: 

This is the main component of the surcharge engine. At a high level, it performs two basic functions, 
1) determines the applicable surcharges and 2) calculates the amounts for each of these surcharges. 

The engine is designed to compute surcharges for an individual charge and location. Given a ticket 
with three charges (e.g., time and distance, refueling, and LDW), three calls would be made to the 
surcharge engine to determine all surcharges for the rental by calling process. The charge engine then 
typically rolls all like surcharges up into single line item. Basic logic flow for the surcharge engine is 
given below: 

Validate Input values to see if mandatory values are passed to engine. 
Find the area hierarchy for the checkout Branch 
Find all the surcharges that are: 

associated with the input charge type 

belong to the hierarchy. 

active as of check out date 
and load them into Array of structs to be processed one by one. 

IF any surcharges loaded into Array, THEN 
FOR every surcharge code in Array 


Check if the renter has tax exemption and 
IF the surcharge is exemptable, THEN 

put the exemption message in the display line 1. 
IF the renter has a contract, 

and the surcharge type is exempted, THEN 
Do not process the surcharge 
IF the renter is eligible for local exemption THEN 
Do not process the surcharge 

Put the exemption message in the display line 1. 
IF based on VREG, THEN 

Get vehicle registration info. 

IF vehicle specific info is not found THEN 

Get the minimum and maximum values from DVC ST SCHGS table 


DO 
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IF the surcharge is based on Vehicle Cost (VCST) THEN 

Get vehicle cost info. 
IF the surcharge is based on Vehicle type (VTYP) THEN 

Get vehicle weight info. 
After all the information is gathered, calculate the surcharge 
Load the surcharge details into out variables. 


DONE 
END IF 


2.7 Calling Process Variations 

The surcharge engine may be called at reservation, open ticket, close ticket, or modify ticket. Calls 
made at the time of reservation differ from those made at open, close, or modify ticket in that the 
specific vehicle to be rented may not be known. In such cases, in order to calculate vehicle based 
surcharges such as those for a vehicle license fee, the engine would assess surcharges based on the 
vehicle class information. 
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3.1 Risks 

There are no items at this time. 

3.2 Assumptions 

• All required vehicle information for surcharge calculations will be passed in by the client 
application, since the surcharge engine will not access vehicle information from the database. 

• The surcharge engine does not perform any database updates. After the appropriate 

jj* ■ surcharges are calculated, they are returned to the calling process. 

Ui 
(*\ 

For daily vehicle license fee surcharge amounts, if the specific vehicle unit number is not 
provided, the surcharge engine will calculate surcharge amount based on the maximum per 
day amount from the DVCJST_SCHGS table. If the unit number is provided but VLF 
amounts are not passed via API, then surcharge is calculated based on minimum per day VLF 
amount from the table. 


si 
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SCHG_CHGJTYPS 

SCHG EFF DT 
RCT CHG TYP 
LINE NBR 
SCHG SCHG ID 
INCLBASE_AMT 
SCHGJDN_LINE 
SEQ_NBR 
RECORD_STATUS 
CREATE BY 
CREATE TIMESTAMP 
CREATE_MODULE 
UPDATEJTIMESTAMP 
UPDATE_BY 
UPDATEJWODULE 


CALC_RLS 

RULE ID 
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MINJJOBJ/AL 
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SCHG SCHG ID 
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UPDATE TIMESTAMP 
UPDATE_BY 
UPDATE MODULE 


SCHG_CDS 
SCHG ID 


EFF DT 
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EXMPT_MSG 
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SCHG SEQ 
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OPTN IND 
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CREATE_BY 

CREATEJTIMESTAMP 

CREATE_MODULE 
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UPDATE_BY 

UPDATE MODULE 


l i 
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CON CON ID 


SCTYP SCHG TYP 


EFF DT 


END_DT 
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CREATE_TIMESTAMP 

CREATE__MODULE 
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UPDATE_BY 

UPDATE MODULE 


J 


'CK 
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AREA TYP 
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DATES REQ FLG 

HI ERARCHY_LVL 

RECORD_STATUS 

CREATE_BY 

CREATEJTIMESTAMP 

CREATEJ/IODULE 

UPDATE TIMESTAMP 

UPDATE_BY 

UPDATE MODULE 


r-OS 


STN CNTR 


STN STN ID 


STN CNTR ID 


STN CNTR EFF DTE 


STN_CNTR_XPR DTE 

STN_CNTR_NM " 

UDA AREA ID 

U DA__ATY_AREA TYP 

RECORD_STATUS 

CREATE_BY 

CREATEJTIMESTAMP 

CREATE J/IODULE 

UPDATE_TIMESTAMP 

UPDATE_BY 

UPDATE MODULE 


XMPTJRENT_SCHG 


SCHG ID 


EFF DTE 
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RECORD_STATUS 
CREATE_BY 
CREATEJTIMESTAMP 
CREATE MODULE 
U PDATEJTIM ESTAMP 
UPDATEJ3Y 
UPDATE JVIODULE 


USR__DFND_AREAS 

ATY AREA TYP 


AREA ID 


AREAJDESC 
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V 
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UDA ATY AREA TYP CHLD 
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CREATE_BY 
CREATE TIMESTAMP 
CREATE JVIODULE 
UPDATE JTIMESTAMP 
UPDATE BY 
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DVC ST SCHGS 


DVC CRY ARIMP CD 
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CAR CLS SUFX CDE 


ST STATE CD 


STRT DT 


MAX_SCHG_AMT 
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GRP ID 

RECORD_STATUS 
CREATE_BY 
CREATEJTIMESTAMP 
CREATE MODULE 
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UPDATE BY 
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1.1 Overview 


This document details the design specifications for the tax engine component of the VRS. This 
covers current VRS functionality and addresses identified tax gaps targeted for iteration 3, except gap 
#28 - the 3 rd party tax data load. Gap 28 will be detailed in its own, separate design document As 
gap 28 primarily concerns tax data, data conversion aspects of taxes will be addressed in that 
document as well. 

1.2 Dependencies 

In order to implement the functionality addressed in this document, the processes calling the tax 
engine must be modified to accommodate the API changes described herein. 

1.3 Data Conversion 

There will be no conversion of tax data from the legacy systems. Rather an initial conversion of 3 rd 
party tax data will be handled as part of Gap 28. Refer to the Gap 28 (3 rd party tax load) design 
document for details involving tax data conversion and initial loading of tax data. 

1.4 Impact Analysis 

The current VRS version of the tax engine consists of a main tax service module and an interface 
(API) to this module. The engine also reads several tables from an Oracle database for retrieving tax 
specific data. 

For Enterprise, much of the VRS code can be implemented unchanged. Most of the database tables 
the engine relies on are being implemented in the Enterprise system with few changes. However, to 
resolve the gaps, changes will still be required to all three areas: the tax data model, the engine API 
and the tax service module. 
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The "tax engine" is a service module with an application program interface (API). Clients make calls 
to the tax engine by passing specific inputs to the engine. The tax engine then retrieves and 
computes applicable taxes based on the inputs and returns this list of taxes to the caller. The API 
defines the specifics of these inputs and outputs. The API definition is given below in the Inputs and 
Outputs sections. 

The engine is a data driven service and relies on tax data maintained in a relational database to 
perform its functions (i.e., if no taxes are set up, no taxes can be calculated by the engine). The 
engine itself does not maintain or update the database. The data maintenance is handled through 
independent processes. For Enterprise this will be a combination of front end user screens and batch 
processes (e.g., 3 rd party tax load). See the relevant documents for details of these processes. 

The engine is designed to compute taxes for an individual charge and location. Given a ticket with 
three charges (e.g., time and distance, refueling, and LDW), three calls would be made to the tax 
engine to determine all taxes for the rental. These calls will typically be made by the charge engine 
when it determines the charges for a rental. The returned taxes get rolled up at the tax code level. In 
this example, three state level sales tax lines may get returned, one for each charge. These would be 
rolled up into a single state level sales tax line. 

The tax engine is written in C and Pro*C and makes up a Tuxedo service. The API includes a 
generic "C" function, TindTaxes' which handles the Tuxedo specifics. Thus developers writing 
clients need no knowledge of Tuxedo to use this service. To improve performance, database access 
is limited within the engine itself. Most data specific to a rental will get passed through the API. 
The engine will access the database to retrieve supporting tax data (e.g., rates), but here as well 
input/output is minimized by routinely caching this data in memory. 

Caching of tax data is handled by a separate Tuxedo service. The service refreshes the cache 
periodically to pick up any data maintenance activity. In the current implementation of VRS this 
occurs once each day. The tax engine will always read from memory except when the cache refresh 
itself is running; during this time the engine will query directly from the database. Tax data tends to 
be static; however, it is important to note that changes made to tax data will not get picked up by the 
engine until the next cache refresh. 
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The tax engine currently supports tax on surcharges and tax on tax scenarios. The engine does not 
currently support varying taxes based on various criteria (e.g., vehicle cost.) To an extent VRS can 
support this by implementing such taxes as surcharges. The surcharge engine has support for 
flexibility in calculation rules and examples of this have been used in VRS to date. 

Taxes Set Up as Surcharges 

As noted, it is sometimes useful to set up taxes as surcharges. This actually means populating 
surcharge tables with tax data (e.g. schg_cds, calcjrls, etc.) The surcharge engine then would pick 
up and process this data, not the tax engine. In these cases, the resultant charge will still be a tax; it 
just allows use of the sucharge engine's more flexible calculations to compute the taxes. A little 
extra care should be given in these cases to consider tax on tax or tax on surcharge implications. For 
example, if such a tax should apply to some other surcharge (i.e. a tax on surcharge scenario) then 
this tax would actually get set up as a surcharge on a surcharge. Similar consideration should be 
given for tax on tax situations and scenarios such as tax exceptions and bundling. 

Requirements for Enterprise 

Enterprise has identified functionality their business needs which is not currently supported by the 
VRS code. These requirements have been documented as 'gaps' mentioned throughout this 
document. These gaps include the need for varying taxes by differing criteria including vehicle type 
and vehicle state of registration. Other gaps concern the data model Enterprise needs the ability to 
define taxes at 'group' level in addition to the state, county, city and district levels currently 
supported by VRS. Some additional data needs to be stored in the tax tables to support relocation of 
branches and audit data as well. For full details of the gaps, refer to the individual gap sheets. 
Proposed design changes for each gap are addressed in the following section. 
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2.2 Detailed Design Description 

In this section, each of the identified gaps which impact the tax engine are addressed. For each gap a 
description is given followed by a design solution. For complete details of each gap, however, refer 
to the individual gap sheets. 

Note before meaningful calls can be made to the tax engine, tax data the engine relies on must be set 
up in the database. As mentioned in the section 2.1 above, for Enterprise this will be accomplished 
through a combination of front end user screens and a 3 rd party tax data load process. In either case, 
the data needed and the general order in which it should be set up is: 

Tax and surcharge hierarchy 
Tax types 
Tax codes 

Taxes per charge types 
Tax exemptions 
Taxable surcharges 

fa I 
% I 

w 2.2.1 Gap 22: Taxes Based on Transaction Type 

il l Gap Description: 

111 

II This is no longer a gap for the tax engine. The gap will be handled through the use of the surcharge 

Q engine. Affected taxes will be implemented as surcharges. Refer to the surcharge engine design 

h» document for further details on the gap and solution. 

Solution: 

Please refer to the surcharge engine design document for solution description. 

2.2.2 Gap 23: Sales Tax Based on Vehicle Type 

Gap Description: 

We need the ability to calculate sales tax based on the type of vehicle being rented. 
Solution: 

Although this is a tax requirement, we plan to accommodate this through the surcharge engine. Refer 
to the surcharge engine for the design details. No changes to the tax engine are currently anticipated 
for this gap. 


iT5 I 


m 
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2.2*3 Gap 25: Allow Group Level Maintenance of Taxes 

Gap Description: 

In VRS, taxes can be defined at the state, county, city and district levels. In Enterprise, however, tax 
decisions can also be made at the "group" level and they need the ability to define taxes at this level 

Solution: 

Group will be added as another level in the tax and surcharge hierarchy. This amounts to a new area 
type and a new column on the BIL_TAS__AREAS table. This will allow defining and maintaining 
taxes at the group level as well as the other levels (state, county, city and district.) The tax engine 
will then be modified to query for taxes at the group level in addition to the existing levels. 

Pseudo code: 

Retrieve Hie five area ideas associated with the branch in question (group, state, county, city, district) 
Retrieve all applicable tax codes in the five areas associated with the branch 

2.2.4 Gap 27: Accommodate Detaching and Reattaching of Branches 

Gat) Description: 

When branches physically change locations, the system needs to accommodate this move within the 
tax and surcharge hierarchy. In addition, the system must retrieve the appropriate taxes, based on 
input date, for where the branch was at that time. 

Solution: 

Effective start and end dates will be added to BEL_TAS_AREAS and STN_CNTR to track, over 
history, where a branch resides within the hierarchy. The tax engine will be modified to vise open 
ticket date in its query of BIL JTAS_AREAS to get the appropriate taxes for a given branch at that 
point in time. This assumes the processes, which maintain these tables, will populate these dates. A 
branch should never have overlapping dates for different rows on BILJTAS_AREAS or 
STN_CNTR, but in such an event, the row with the most current data (closest effective start date 
prior to the open ticket date) will be used. 
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Pseudo code: 

Retrieve the five area ids (group, state, county, city, district) from BIL_TAS_AREAS for the given 
branch where open ticket date is between the effective date and end date 

IF multiple rows returned, use the row with the latest effective start date prior to open ticket date 
Retrieve all applicable tax codes for the five area ids retrieved 

2.2.5 Gap 29: Store Audit Data on Tax Tables 

Gap Description: 

Enterprise has standard audit columns they use on all tables to track change history. We need to add 
these columns to several of the tables being ported from the VRS data model to the Enterprise data 
model. 


1. Create date & timestamp 

2. Create user id 

3. Change date & timestamp 

4. Change user id 

Any process, which updates these tables, needs to update these columns. This does not impact the 
tax engine directly as it currently does not update any tables. 

2.2.6 Gap 30: Print Tax Exempt Charges on Invoices 

Gap Description: 

The current VRS code suppresses printing tax exempt charges on invoices. For the Enterprise 
implementation exempted taxes should print showing the tax rate, but with a zero amount. 


Currently the tax engine sets the 'activity flag 9 for exempt taxes to 'NN' meaning "non active, no 
show". In VRS this has the effect of suppressing display on screens or printing on documents for 
exempted taxes. The code will be changed to set this flag to 'AS' ("active show") and to set the tax 
amount to zero. Note the actual suppression or display of the charge lines is not controlled by the tax 


Solution: 


Four columns will be added to each of the tax and surcharge tables: 


Solution: 
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engine. Other programs handle printing of documents and may need to change to support this 
requirement 

2.2.7 Gap 141: Accommodate Taxes Based oh Vehicle State of Registration 

Gap Description: 

This gap is specific to North Carolina. As NC vehicles are purchased the Motor Vehicle Highway 
Tax is prepaid. When these vehicles are rented in NC, a surcharge is used to recoup this money back 
to Enterprise. However, non NC vehicles are also rented in NC (notably South Carolina vehicles.) 
These vehicles have not had the NC MVHT prepaid, but the tax is still applicable. For these rentals, 
the tax must be charged and remitted to the government. So both the tax and the surcharge must be 
set up, but only one should ever be applied depending on if the vehicle was purchased in NC or not. 


Solution: 



Although this gap involves a tax, we will accommodate it solely through use of the surcharge engine. 
In brief, both the tax and the surcharge will be set up as surcharge codes and the surcharge engine 
will determine which to assess based on the vehicle owning state. This solution involves no impact 
to the tax engine. Refer to the surcharge engine detail design document for full details. 
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23 Database Table Impacts 

The following changes are required to the tax and surcharges tables: 

• Define a new area type for group and add group id to BIL_TAS__AREAS (gap 25) 

• Add effective and end date columns to BILJTASAREAS and STN_CNTR (gap 27) 

• Add the following audit columns to all tax and surcharge tables, except those with existing 
audit field information.(gap 29) 

1 . Create date & timestamp 

2. Create user id 

3. Create module 

4. Update date & timestamp 

5. Update user id 

6. Update module 

7. Record status 


Definitions for the affected tables are given below with the highlighted portions indicating additions 
or changes to the VRS versions of these tables. Note some of this information is duplicated in the 
surcharge engine design document. 


2.3.1.1 BIL_TAS_AREAS Table 


This table stores the tax and surcharge hierarchy for each branch. 


Columns: 

STN_STN_ID NOT NULL VARCHAR2(10) 

CRY_ARIMP_CRY_CD NOT NULL VARCHAR2(2) 

STPRJD NOT NULL ^03^16) 

COUNJD NOT NULL ^MMM((^ 

CITYJD NOT NULL tf0§tfg3&^ 

DISTJD NOT NULL ^CBE^^ 

SCNTR_STN_CNTR_ID NOT NULL VARCHAR2(1) 

BIL'TAS_AlfeAS EFElDIB 'v^'-NOTNP^^i v^-^&^ 
BIL-TASiAREAS XftMJffiv ^AlM^^^Kf if \t)kim 

SREATjEjBY ' - \/+ ^ : >NOTNULL (V. VARCBAR2<S0) 

^Ai^cjii^sxi^ ; ^ ; . . * wMi : ; ,o r • : : SbEate ' 
iPMTEjtiMEStA^ :t::^;^sta;^;:; X,i5&ns ' 

iPDAmiMODULE ; * , ; vf 
Primary Key: 

STN_STN_ID, SCNTR_STNCNTRJD, &1L^TA^AREA%B?FJOTE 


Last Save Date: 1 1/5/200 1 1 0: 1 0 AM 


Page 12 of 22 


Tax Engine Detail DesignJB 


rent-a-car 


ECARS v2.0 - Accurate Out the Door Pricing 
Detailed Design Specification 


perotsystems 


2.3.1.2 STN^CNTR Table 

This table associates a given station to the user defined area to which it belongs. 


Columns: 

STN_STN_ID 
STN_CNTRJD 
STN_CNTRJNM 
UDA_AREAJD 
UDA_ATY_AREA_TYP 
§TN_CNTR_EFF -DIB ' V"' 
SIN 

Record 


NOTNULL 

NOTNULL 

NOTNULL 

NULL 

NULL 


VARCHAR2(I0) 
VARCHAR2(I) 
VARCHAR2(30) 
VARCHAR2(10) 
VARCHAR2(10) 



Primary Kev: 

STN_STN_ID, STN_CNTRJD 5 Sfj* 

2.3.1.3 TX^CDS table 

This table holds the taxes for different areas that are defined in the Taxes and Surcharge Hierarchy. 
Columns: 


TX_CD 

NOTNULL 

VARCHAR2(15) 

STRT DT 

NOTNULL 

DATE 

CREAT BY 

NOTNULL 

VARCHAR2(30) 

CREATJDT 

NOTNULL 

DATE 

CRY ARIMP CRY CD 

NOTNULL 

VARCHAR2(2) 

EXMTP IND 

NOTNULL 

VARCHAR2(1) 

TX NM 

NOTNULL 

VARCHAR2(35) 

TX RT 

NOTNULL 

NUMBER(6, 3) 

UDA AREA ID 

NOTNULL 


UDA ATY AREA TYP 

NOTNULL 

VARCHAR2(l6) 

CR CHG DESC 

NULL 

VARCHAR2(35) 

GLT SEQ 

NULL 

NUMBER(6) 

INACTV DT 

NULL 

DATE 

LST UPDT BY 

NULL 

VARCHAR2(30) 

LST UPDT DT 

NULL 

DATE 

MAX TX AMT 

NULL 

NUMBER(15,3) 

MAX TX PCT 

NULL 

NUMBER(6, 3) 

RCT CHG TYP 

NULL 

VARCHAR2(5) 

TXTYP TX TYP CD 

NOTNULL 

VARCHAR2(4) 

TAX CDE LOND DESC 

NULL 

VARCHAR2(iO0) 
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2.3.1.4 TXj:HG_TYPS Table 

This table stores tax codes associated with each charge type. 
Columns: 

RCTCHGJTYP NOT NULL VARCHAR2(5) 

TXCJX_CD NOT NULL VARCHAR2(15) 

TXC_STRT_DT NOT NULL DATE 

SEQJSGBR • NOT NULL NUMBER(1) 

TXC_TX_LVL NULL NUMBER(3) 
RECORD " 



2.3.1.5 TX_TYPS Table 

This table is used to store tax types. A tax type is used to classify taxes into categories. Multiple 
taxes can be grouped under one tax type. 

Columns: 

TXJTYPCD NOT NULL VARCHAR2(4) 

TX_TYP_DESC NOT NULL VARCHAR2(25) 

EXMPTBL FLG 



2.3.1,6 TXBL_SCHGS Table 

This table holds taxable surcharges. 
Columns: 

SCHGJSCHGJD NOT NULL VARCHAR2(15) 

SCHGJEFFJDT NOT NULL DATE 

TCD_STRTJDT NOT NULL DATE 

TCDJTX_CD NOT NULL VARCHAR2(15) 

81CORD_STATUS ; ^ *' V NU£L ; : ' : " > * 1 " VASCHAB2t2) 

GREATEBY ■ : A** v;>OTNULL ; 1 • vMeHAR2(30) 

jOREATEJOMESTAMP , }JSBI&i^*y ^ ^'V^DATE 

BSeaieImodule - ^ s >>>\> \ " wji%;>% > ^ >^J^QHj^i624) 

UPDATEJTIMESTAMP V?: H N0L^\'r' - %; V%ATE 
UPDATE J*Y\ : \ , : <{ :^mLL l 'y^ : % , ; VAR€HAR2(30j 

UPDATE JviGDT^fi < _ ^ . ; ^i^ULL V, V Yi^HAE2^0i4) 
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2.3.1.7 AREA_RLTNS 

This table holds the parent/child relationships between area ids. 


Columns: 

UDA_ATY_AREA_TYP 

UDA_ATY_AREA_TYP" 

UDA_AREA_ID_PRNT " 

UDA__AREAJD_CHLD 

^CORDJSTATUS:;^^ 
fREATE^BYVw ,, 

C^AfE^MObULE 
iPE^IE^IMES 

llPD^llJVIODbLE 


PRNT 
CHLD 


yARpHAR2(X0) 
YARGHAR2{10) 
VARCHAR2(10) 
VARCHAR2(10) 
^ARC1MR2(2) 


NOT NULL 
NOT NULL 
NOT NULL 
NOT NULL 
NULL c. . ^ 
^OtNULL ; 

- 1^£>> * {^;¥AReHAR2(1024) 


2.3.18 AREAJTYPS 

This table holds the valid area types for area ids with descriptions of each. 
Columns: 


AREAJTYP 
AREA_TYP_ACT 
AREAJTYPDESC 
AREA_TYP_SHRT_DE SC 
HIERARCHYLVL 
DATES REQ FLG 


NOT NULL 

NOT NULL 

NULL 

NULL 

NULL 

NULL 


VARCHAR2(10) 
VARCHAR2(3) 
VARCHAR2(35) 
VARCHAR2(10) 
NUMBER(2) 
VARCHAR2(1) 



2.3.1.9 TAX^EXEMPTIONS 

This table indicates tax exemptions by contract. 
Columns: 


CON ID 

NOT NULL 

NUMBER(8) 

ST STATE CD 

NOT NULL 

VARCHAR2(6) 

ISSUE DT 

NOT NULL 

DATE 

CERT NBR 

NOT NULL 

VARCHAR2(16) 

EXPIRATION DT 

NULL 

DATE 

LST CHG DT 

NULL 

DATE 

LST USR ID 

NULL 

VARCHAR2(30) 

MICROFISCHE NBR 

NULL 

NUMBER(9) 

CRY ARIMP CRY CD 

NOT NULL 

VARCHAR2(2) 

TXTYP TX TYP CD 

NOT NULL 

VARCHAR2(4) 
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2.4 Inputs 

The table below details the inputs for clients calling the tax engine via the C function, FindTaxes. 
FindTaxes is not actually part of the tax engine per se. It is a "wrapper" function to insulate client 
callers from Tuxedo specifics. It is called just as any other C function. 


Tax Engine Input Parameters 

Input Parameter 

Descrwtion 

fjlfl Viold Name 

JVluflu 

atory 

Type 


Source of 
Data 

Stan3ard Header 

The" content of this tt^&tf 
yM Be used for defeugging, 
meirtest|uppor4 

Refei to staaidard, header 
d(^^eift%layoiit and 
popu^olttirMes 

Yes 



All Clients 

Amt 

Charge amt 

FN ROP CHG AMT 

Yes 

double 


Client App 

Chg typ 

Charge type 

FN ROP CHG TYP 

Yes 

string 

5 

Client App 

Co cry 

Check out country code 

FN ROP CO CTY 

Yes 

string 

2 

Client App 

Co stn 

Check out station code 

FN ROP CO STN ID 

Yes 

double 


Client App 

Co state cd 

Check but state code 

FN: ROP CO STATE CD 

tes 

string 

2 

Client App 

Co date 

Check out date 

FN ROP CO TMSP 

Yes 

string 

12 

Client App 

Exempt flag 

Tax exempt flag 

FN ROP TAX XMPT FLG 

Yes 

char 

1 

Client App 

Inclusive flag 

Tax inclusive flag 

FN ROP TAX INCL FLG 

Yes 

char 

1 

Client App 

Schg id 

Surcharge id 

FN ROP SCHG ID 

No 

string 

1 

Client App 

Con id 

Contract id 

FN ROP CON ID 

No 

long 

4 

Client App 

Counter id 

Counter id within a station 

FN ROP CO COUNTER ID 

Yes 

char 

1 

Client App 


2.5 Outputs 


The following table details the outputs returned from the tax engine: 


Tax Engine Output Parameters 

Output Parameter 

Description 

FML Field Name 

Type 

Size 

Source of Data 

Error code 

Error code 

RN ROP ERR STATUS 

int 

4 

tax engine 

Rec count 

Number of taxes returned 

FN ROP REC COUNT 

int 

4 

tax engine 

Tax_basis 

Base amount tax was 
applied to 

RN_ROP_TAX_BASIS 

double 

8 

tax engine 

Tax rate 

Tax rate 

FN ROP TAX RATE 

double 

8 

tax engine 

Tax cd 

Tax code 

FN ROP TAX CD 

string 

15 

tax engine 

Tax strt tmsp 

Tax start date 

FN ROP TAX STRT TMSP 

string 

16 

tax engine 

Tax amt 

Calculated tax amount 

FN ROP TAX AMT 

double 

8 

tax engine 

Tax_max_amt 

Maximum amount for this 
tax 

FN_ROP_TAX__MAX_AMT 

double 

8 

tax engine 

Tax desc 

Line item description 

FN ROP TAX DESC 

string 

35 

tax engine 

Chg typ 

Charge type 

FN ROP CHG TYP 

string 

5 

tax engine 

Git seq nbr 

GLT sequence number 

FN ROP GLT SEQ NBR 

long 

4 

tax engine 

Tax_xmpt_flg 

Flag to indicate if tax was 
exempted or not 

FN_ROP_TAX_XMPT_FLG 

int 

4 

tax engine 

Act flag 

Activity flag 

FN ROP ACT FLG 

string 

2 

tax engine 

Taxable ind 

Taxable indicator 

FN ROP TAX IND 

char 

1 

tax engine 

Tx typ cd 

Tax type code 

FN ROP TX TYP CD 

string 

4 

tax engine 
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Sample Input/Output from the Tax Engine 

The Following is an example of output produced by the tax engine for a given set of input values: 


INPL 

FTS 

Charge amount 

50.000 

Charge type 

00001 

Check out country 

US 

Check out station 

MSPT01 

Check out state code 

MN 

Check out date 

200104200000 

Tax exempt flag 

N 

Tax inclusive flag 


Surcharge id 


Contract id 

0 

Counter id 

1 


OUTPUTS 

Error code 

0 

Number of taxes 

1 

Tax basis 

50.000 

Tax rate 

6.500 

Tax code 

US2MNHEN1 

Tax start date 

19980716 

Tax amount 

3.250 

Maximum tax amount 

99999.990 

Tax description 

STATE TAX 

Charge type 

00050 

GLT sequence nbr 

753 

Tax exempted flag 

0 

Activity flag 

AS 

Taxable indicator 


Tax type code 

STAX 
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2.6 Detailed Process Flow 


Client 


e.g. Charge engine 




Tax Engine Tuxedo server 



ROPTS0180A 


Tax engine 
service 


ROPTSD180C 


Tax cache 
refresh service 


ROPTS0I80A 
DataAccess 


A given client typically calls the tax engine via the "wrapper" C 
function, FindTaxes. This in turn calls ROPTS0J80_SvcCall which 
handles translation of C variables into corresponding FML buffers. 
It also makes the actual call to the engine itself The engine 
retrieves and computes taxes which are returned through the same 
path back to the calling client 


Database 


The tax engine service is composed of two mam modules. The heart 
of the service is m the DataAccess module. Note the service 
attempts to read all tax data from a memory cache in favor of the 
actual database. ROPTS0I80C is a separate service which 
periodically refreshes the cache to pick up any tax data 
maintenance activity. 


Each of the main pieces is discussed below: 
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FindTaxes: 

This function will initiate a call to the tax service for a given station and charge type. The tax service 
will return all applicable taxes in a structure. FindTaxes reads these and groups taxes of like tax 
codes. This produces a set of taxes of unique tax codes which it moves an output structure to return 
to the calling client (this structure must be allocated by the client calling FindTaxes). FindTaxes 
itself is a pure C function and is called as such. All the Tuxedo specifics are managed by FindTaxes 
and the follow on routines it calls. This insulates client developers from the need for any Tuxedo 
knowledge. As far as clients are concerned, this function is the API to the tax engine. The inputs 
and outputs of this function are given in the inputs and outputs sections of this document. 


ROPTS0180A SvcCall: 

This function handles manipulation of 'C variables into Tuxedo buffers and makes the actual 
Tuxedo call to the tax engine. Outputs from the engine are converted back to typical C variables and 
returned. Use of this function by FindTaxes frees clients from any need for Tuxedo knowledge or 
manipulation. 

The specific functions it performs are a series of fairly straightforward Tuxedo steps as follows: 

1. Allocate VEW32 input buffer 

2. Copy C input parms into VIEW32 buffer 

3. Allocate FML32 input buffer 

4. Convert the VIEW32 input buffer into the FML32 input buffer 

5. Issue tpacall to the tax service with the FML32 input buffer 

6. Allocate both a VIEW32 and FML32 output buffer 

7. Issue tpgetrply for service response using the FML32 output buffer 

8. Convert the FML32 output buffer to the VIEW32 output buffer 

9. Copy the VIEW32 output data into the C output parameters and return 


ROPTS0180A: 

This is the actual entry point to the tax engine proper. It takes the FML32 buffer data it was passed 
and converts this back to VIEW32 format in order to pass the inputs to the database access module in 
more "C like" fashion. It then makes the call to the database access module using the VIEW32 
buffers. Upon return, it converts the VIEW32 output buffer to an FML32 buffer and issues a 
tpreturn. 
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This is really the heart of the tax service. At a high level, it simply does two things, 1 : gathers all the 
taxes applicable and 2: calculates the amounts for each of these taxes. 

Getting the taxes has a couple of nuances. First, retrieving the taxes depends on whether surcharge 
id has been populated on the inputs. This indicates a tax on surcharge scenario and dictates 
somewhat different rules for getting taxes. The mechanics are also noteworthy. Tax data is typically 
cached in memory, so a routine checks this first. If the data is there, no database access is needed. 
Otherwise the data is retrieved from the database. In either case, once the taxes are retrieved, we 
move to the calculation step. 

The calculate tax routine loops through all the taxes fetched and processes each individually. Tax 
exemption is checked first. If the tax is exempt, the associated activity flag is set to "non active, no 
show" (note, however, this will change with gap 30.) The output tax data is then simply filled mostly 
with the retrieved tax data. The dollar amount to which a given tax is applied is known as the tax 
basis and this must be determined. Each tax has an associated 'level' and 'sequence' which dictate 
rales for determining basis - mainly whether or not to include the charge amount itself in the basis 
and whether to include prior tax amounts in the basis for the particular tax being calculated. The 
SI actual tax amount then is computed as basis times rate. 


2.7 Calling Process Variations 

At this time, the charge engine is assumed to be the primary client of the tax engine. This does not in 
any way preclude the possibility of other clients. There are no calling process variations at this time 
as there is only one caller. 
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No items at this time. 

3.2 Assumptions 

No items at this time. 

3.3 Issues 

• The proposed solution to Gap 30 states that tax rate and amount will be set to zero for exempted 
taxes. Is there any need to actually calculate the tax amount exempted? It was suggested this 
might be needed in Canada for accrual purposes. 
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BIL_TAS_AREAS 

STN STN ID 

SCNTR STN CNTR ID 

BiL TAS AREAS EFF DTE 


CRY_ARIMP_CRY_CD 
STPR ID 
GRP ID 
COUNJD 
DISTJD 

B IL_TAS_AR E AS__XPR_DTE 
RECORD STATUS 
CREATE J3Y 
CREATEJWODULE 
CREATE J-IMESTAMP 
UPDATE BY 
UPDATE MODULE 
UPDATE TIMESTAMP 
CITY ID 


AREAJTYPS 


AREA TYP 

AREA TYP ACT 

AREAJTYP DESC 

ARE A JTYP~S HRTJD ESC 

DATES_REQ_FLG 

R ECORQ_STATUS 

CREATE BY 

CREATE JTI M ESTAMP 

CREATEJWODULE 

U P DATE JTI M ESTAM P 

UPDATE_BY 

UPDATEJWODULE 


t 


USR_DFND_AREAS 


ATY AREA TYP 
AREA ID 
AREA DESC 
INV CNTLJND 
VPA_VPAJD 
CITY ALJAS_FLG 


TX_CDS 


TX CD 


STRTDT 


CREAT BY 

creat~dt 
exmptjnd 

TXJMM 
TX_RT 

UDA AREA ID 
UDA_ATY AREA TYP 
CR^CHG DESC 
GLT_SEQ 
INACTV DT 
LST_UPDT_DT 
LST UPDT_BY 
MAXTX AMT 
MAX TX_PCT 
RCTCHGJTYP 
TXTYP_TX TYP CD 
TAX_CDE LONG.DESC 


T 


~i — OS TXC TX CD 


TXJSHGJTYPS 


RCT CHG TYP 


TXC STRT DT 


RECORD STATUS 
CREATE_BY 
CREATEJTIMESTAMP 
CREATE MODULE 
UPDATE J*IMESTAMP 
UPDATE BY 
UPDATEJUODULE 
SEQ_NBR 
TXC_TX LVL 


TXJTYPS 


TX TYP CD 
TXJTYP_DESC 
EXMPTBL FLG 
RECORD STATUS 
CREATE_8Y 
CREATE TIMESTAMP 
CREATE J/IODULE 
UPDATE JTIMESTAMP 
UPDATE BY 
UPDATE MODULE 


T 


<X SCHG EFF DT 


TXBL.SCHGS 


SCHG SCHG ID 


TCP STRT DT 


TCP TX CD 


RECORD STATUS 
CREATE_BY 
CREATEJTIMESTAMP 
CREATE MODULE 
UPDATE TIMESTAMP 
UPDATE BY 
UPDATE MODULE 


TAX_EXEMPTjONS 


CON ID 

TXTYP TX TYP CD 
ST_STATE CD 
ISSUE DT 
CERT NBR 
EXPIRATION DT 
LST CHG_DT 
LST USRJD 
MICROFISCHE NBR 
CRY_ARIMP_CRY CD 


AREA_RLTNS 


UDA ATY AREA TYP PRNT 
UDA ATY AREA TYP CHLD 
UDA AREA ID PRNT 
UDA AREA ID CHLD 
RECORD STATUS 
CREATE_BY 
CREATE TIMESTAMP 
CREATEJWODULE 
UPDATE TIMESTAMP 
UPDATE_BY 
UPDATE MODULE 


STN.CNTR 


STN STN ID 

STN CNTR ID 

STN CNTR EFF DTE 


STN CNTR NM 
STN_CNTR_XPR DTE 
RECORD_STATUS 
CREATE BY 
CREATE MODULE 
CREATEJTIMESTAMP 
UPDATE BY 
UPDATE MODULE 
UPDATE TIMESTAMP 
UDA_AREAJD 
UDA_ATY AREAJTYP 
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flow to address a unit pended ticket 

Allison Bruhn 

07/26/2001 

1.5 

5 th revision-put in flow to address that locking 
while on the rates/rules sub-app will not force a 
save; import into Req Pro 

* Allison Bruhn 

08/01/2001 

1.6 

6 th Revision-changed the flow regarding 
automatic locKing arter ou minutes to o minutes, 

also added flow to include a force save to 
callbacks; added flow for pre-write; added flow for 
differentiating between printing a pre-write ticket 
and just saving it (currently users can only print a 
pre-write); broke up the flow different user 
unlocking to describe what happens when a 
different user with the same security rights 
unlocks it versus a different user with different 
security rights unlocking it 

Allison Bruhn 
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Business Use-Case Specification: Application Locking 


1. Application Locking 

1.1 Brief Description 

The purpose of this use case is to show what the user does to lock and unlock the ECARS 2.0 application. 
The application may be opened by the user that initially locked it or by another user via a log in screen. 
This locking mechanism will extend to all areas of the application. Note: With regards to the locking of a 
unit-pend or pre-write, these are still an open issue depending on how Open Ticket decides to handle. 

2. Flow of Events 
2.1 Basic Workflow 

2.1.1 Use Case Begins 

This use case begins when a user chooses to lock the ECARS 2.0 application. This functionality should be 
available during any type of transaction within the application (i.e. reservation, open ticket, callbacks, rates 
test window, etc.). If there is no activity on a terminal for five minutes see alternate flow Locking After 
Five Minutes. 

2.1.2 Lock Icon 

The user initiates the lockin g process (i .e.. clicking an icon and via a hot kev). T^e system will force a 
save to the information within a reservation, open ticket, close ticket, and callback prior to the application 
being locked. 

2.1.3 Locked Screen 

This locked screen will replace the current sc reen in the application . If the user is in the process of 
opening a ticket and chooses to lock it, see alternate flow Locking of Open Ticket . If the user is in the 
process of unit-pending a ticket and chooses to lock it, see alternate flow Unit-Pending a Ticket If the user 
is in the process of pre-writing a ticket and chooses to lock it, see alternate flow Pre- Writing a Ticket. 

2 1.4 Locked By Display 

UmnJ9Mng±eMmM%t ion. some t vp_e„o,f messag e should be di^ayMin&c^^^ application is 

locked ky.a_particular user (TBD of what exactly should show). 

2.1.5 Unlocking of Application 

At anv poin t in time if a user choos es to work on the terminal in which t he^cree n or screens have been 
locked, thev must go through an u nlocking p rocess. The system pro mpts the user t qenter their user i d and 
password which are required to unloc k the application . 

2.1.6 Validation of Entered Information 

If the same user who locked the app unlocks it. access to the application is immediately g ained. The 
system will return to th e current s creen in the application after unlocking . If a different user is unlocking 
the application see alternate flow New User Unlocking. If the user id and password entered is not valid see 
alternate flow Invalid User Id and Password . If either the user id or password field is left blank see 
alternate flow Not Enough Information . 

2.17 The Use Case Ends 

The user has successfully locked and unlocked the ECARS 2.0 application. 


Confidential 


©Enterprise Rent-A-Car, 2000 


Page 4 



Version: <L0> 

Rental Redesign/EC ARS 2 

Date: <dd/mmm/yy> 

<document identified 


2.2 Alternative Workflows 
2. 2. 1 Invalid User Id and Password 

The system does not recognize the user id and password entered and an error mess age is produced . The 
user can choose to re-enter the information required to unlock the application and the use case continues at 
the main flow Unlocking Of Application . If the information entered is invalid the use case ends. The user 
can also choose to cancel at anv time . 

22.2 Not Enough Information 

The user has left a field blank (either user id password or botlfl when attempting to unlock the application 
and an erro r message jsj3rpduced . The user can choose to re-enter the information required to unlock the 
application and the use case continues at the main flow Unlocking of Application . If the information 
entered is invalid the use case ends. The user can also choose to cancel at any time. 

2. 2. 3 Locking After Five Minutes 

If the terminal is idle for five minutes wit h no mouse or keyboard action whatsoever, the idle screen should 
be locked automatically. A forced save will occur . Once a user decides to act on the locked screen, the 
use case continues at the main flow Unlocking of Application . 

2.2.4 Locking of Ticket 

This is still an open issue. We will have to wait until open tickets decides how to implement. If during the 
opening of a ticket the user chooses to lock the application, the ticket reacts as if it is a pre-write. Last 
name is the only item required to lock the application during the opening of a ticket. Once the user unlocks 
the application they can complete the ticket 

2.2.5 Unit-Pending a Ticket 

This is still an open issue. We will have to wait until open tickets decides how to implement The user 
chooses to lock a ticket that they have unit-pendeA Once they unlock it, the ticket will remain in a unit- 
pended state until the user assigns a unit to that ticket 

2. 2. 6 Pre-Writing a Ticket 

This is still an open issue. We will have to wait until open tickets decides how to implement. The user 
chooses to lock a ticket that is a pre-write status. 

2.2.6.1 Pre-Write With Save and No Print 

The user chooses to save the pre-write and continues working with the application (TBD). 

2.2.6.2 Pre-Write With Save and Print 

The user chooses to save the pre-write and print it out (in current state all a user can do it print) and 
continues working with the application (TBD). 

2. 2. 7 New User Unlocking with Same Security Rights 

The system takes the information entered hv the n ew user wanti ng to unlock the application and passes it to 
the Ap plicatio n Security System for a uthentication. The application security system confirms the user id 
and password are valid and that the user has the same securi ty- rights as the previous user. The system wil l 
return to the current screen in the application after unlocking . If the user id and password entered is not 
valid see alternate flow Invalid User Id and Password . If either the user id and password field is left blank 
see alternate flow Not Enough Information . 

2.2.8 New User Unlocking with Different Security Rights 

The system takes the information entered bv the new user wanting to unlock the application and passes it to 
the Application Security System for authentication. The application security system confirms the user id 
and password are valid but the new user has lesser security rights from the previous user . 
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2.2.8.1 System Closes Screens 

The svstem closes any of the screens that were previously opened before the application locking occurred 
and the user with lesser security lig hts is returned to the sp lash screen . The new user can then work with 
the application, based on their security access, if they choose to do so. 

2.2.9 The use case ends. 

3. Special Requirements 

3.1 The requirements for the application locking are: 

• An idle screen should be locked automatically by the system after a system-determined idle period 

• The user should be able to lock a screen from any screen whenever desired 

• The locked screen will replace the current screen in the application 

• The locked screen will require the user to log in to unlock the screen 

• The system will return to the current screen in the application after unlocking 

• The user unlocking the application will replace the user id of the user who locked the application 
for the purposes of security and authentication. 

• When authentication takes place, the system should respond based on the new user's rights rather 
than the old 

3.2 System generated notes 

• The user that is authenticated will be the employee number in the system generated note, the user 
generated notes, and the updated by field in the database. 

4. Pre-Conditions 

• It is assumed that the user has successfully launched the ECARS 2.0 application. 

5. Post Conditions 

5.1 < Post-condition One> 

6. Extension Points 

6.1 <name of extension point> 

7. Open Issues 

• What hot key should be used to lock 

• If any sub-application is going to be locked (other than reservation, open, close, and callbacks) 
such as rates, taxes/surcharges, etc. is there going to be a save as well or not? 

• How is locking of pre-write going to work? (dependent on what open ticket is going to do) 

• How is locking of a unit pend going to work (dependent on what open ticket is going to do) 

• How is locking of an open ticket going to work? (dependent on what open ticket is going to do) 

8. Future Scope 
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3. Special Requirements 

3.1 Upon Locking the Database lock associated with the record shall be removed. 

4. Pre-Conditions 

4.1 For successful locking without data loss, the active record must meet the minimum 
requirements as specified by the sub-applications "Save" function. 
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5.1 Application is in the "Locked" state with the Application Locked Screen active. 

5.2 Application returned control to one of the sub-applications. * 

6. Extension Points 
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Business Use-Case Specification: Change Password 


1 . Change Password 

1.1 Brief Description 

The purpose of this use case will describe what a user does to change their password. A user may be 
prompted by the system to change their password if it has expired, when it is set to its default value (i.e. 
when a new user logs in for the very first time), or a user may choose to change it on their own. 

2. Flow of Events 
2.1 Basic Workflow 

2.1.1 Use Case Begins 

This use case begins when a user is ei ther prom pted bv the sy stem (due to an expired password or a user 
lagging in fojlthe veQLfimtiini^oiichooses to change their p assword on their own. A tlh^tim^a_uMris 
initially logging in. the system prompts them to change their passwo rd as it ha s expired . If the user 
chooses to change their password, with no prompt by the system, see alternate flow User Chooses to 
Change Password . 

2. 1 2 System Displays Entry Field 

The system displays fields where a user is required to enter information necessary, to change their 
password . 

2.1.3 User Enters Required Information 

The user en ters the required inform ation that includes their user id. existing password, their new password. 
and confirmation of their new password . 

2.1.4 System Sends Information For Processing 

The system sends this newly entered information to the Application Security System for processing. 

2.15 System Validates Information 

The application security system confirms the information entered is v aLid^fthejjs er changed their 
password on their own some message is displayed to the user confirming the password change was 
sygges&MJfthe user, chang ed their password due to it expiring, nmn^s^e wQlbe shown to theuser that 
the change was successful . The user can continue working with the ECARS 2.0 application. 

2.1.6 No Validation By System 

The system does not validate the information entered by the user. If the existing password entered is not 
valid, see alternate flow Invalid Password Entered . If the newly entered password entered matches a recent 
password, if the confirmation password entered is not valid, if the information entered does not fall within 
the required length parameters, or one of the required fields is left blank see alternate flow Invalid 
Information Entered . 

2. 1. 7 The Use Case Ends 

The use case ends as the user has successfully changed their password and can continue working with the 
application. 
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2.2 Alternative Workflows 

2. 2. 1 User Chooses to Change Password 

The user, for whatever re ason, choose s to change their existing password with no svstem prompt H.e, bv 
clicking an icon, etc.) . The. ns ft rasa continues at the main flow System Displays Entry Fields . The user 
may also choose to cancel at any time. 

2.2.2 Invalid Password Entered 

The system does not recognize the existing password that is entered . The user can choose to re-enter the 
information and the use case continues as the main flow Svstem Sends information for Processing . If the 
user does not choose to re-enter the information, the use case ends. If the user exceed&ihe number of sign- 
on attempts allowed the use case ends . 

2.2.3 Invalid Information Entered 

The newlv entered password is the same as the existi ng password 
The confirmation of the newlv entered password is incorrect 

The newlv entered password and /or confirm ation does not fall within the length 
requirements (no less than six and no more than thirty) 

One or more of the required fields is left blank 


The user will receive some sort of error message should anv of the above scenarios apply . The user can 
choose to re-enter the information and use case continues at the main flow System Sends Information for 
Processing . If the user does not choose to re-enter the information, the use case ends. The user can also 
choose to cancel at anv time . 

2.2.4 The use case ends 

3. Special Requirements 

3.1 Password Length 

The password entered must be at least six characters in length but no more than thirty 

4. Pre-Conditions 

5. Postconditions 

5.1 <Post-condition One> 

6. Extension Points 
6.1 <name of extension point> 

7. Questions 

8. Future Scope 
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Business Use-Case Specification: E-Location Fake 

Out 


1 . E-Location Fake Out 

1.1 Brief Description 

The purpose of this use case is to describe what a user goes through to emulate their own group branch 
while they are at a different Enterprise location. For example, this may be done if they have no access to 
their own terminals or power has been completely lost for some reason. For the purpose of a rental branch, 
this type of emulation may also occur to perform certain branch duties such as the End of Month Report or 
the completion of handwritten tickets. 

2. Flow of Events 
2.1 Basic Workflow 

2.1.1 Use Case Begins 

This use case begins when a user decides t o_orj^requlm d to emulate jj^ 

terminal location. The user must contact their assign e_d_admtoistmt or in order to gain such access . 

2. 1. 2 Administrator Contacted 

Once the administrator is notified, they will access the Admin Express applicatioif. The administrator then 
selects the 4 Application User' function and the process begins that will eventually allow the particular user 
requesting emulation to gain access. If the user chooses to call the administrator once they are complete 
see alternate flow Remove Location/Un-Assign User (note: the user is not required to call back). 

2.1.3 Administrator Selects User 

The administrator selects which User has requested access, the Edit User Security function and the 
Substitute Location function (the fake-out location)— noted in the Substitute Location Access Use Case 
(application security 1.6). 

2.1 .3.1 User Credentials Displayed 

The system will display the em ployee 's name, user id. and group branch based on the User the 
Administrator has selected . The administrator then confirms this is the correct employee selection. 

2.14 Emulation Rights Granted 

The user is granted access from the substituteJocaiion to emulate^lffe^ location mujthg 

within die same group as the branch requesting the emulation (see Special Requirements section). 

2. 1 5 System displays one of the following conditions (based on substitute location access use case) 

2.1.5.1 Previous Day Emulation 

If the user previously had a substitute location for a day other than current day, display that for 
informational purposes. 

2.1.5.2 User Never Has Had Substitute Capabilities 

If the user has never had access to a substitute location, the system will indicate this. 

2.1 .5.3 Previous Substitute Capabilities For Current Day 

If the user has already had access to the substitute location earlier in the current day, the system will display 
that. 
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2.16 The Use Case Ends 

The use case ends as a user successfully emulated one group branch from another group branch location. 

2.2 Alternative Workflows 

2.2.1 Remove Location/Un-assign User 

The user has completed the emulation. The Administrator selects the location the user requests to unassign. 
The administrator commits this removal process and the substitution fake-out is complete. 

2.22 The Use Case Ends 

3. Special Requirements 

• An E-location fake out can only occur from a branch within the group as the branch being 
emulated 

• The administratively configured access is valid for ECARS 2.0 logons that occur within the 
business day requested only. If they need it past that point they will have to call their assigned 
administrator. 

4. Pre-Conditions 

5. Post Conditions 

5.1 < Post-condition One> 

6. Extension Points 
6.1 <name of extension point> 

7. Questions 

8. Future Scope 
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Business Use-Case Specification: Launch 
Application/User Authentication 


1 . Launch Application/User Authentication 

1 .1 Brief Description 

The purpose of this use case is to describe the interaction that occurs between the user and the system 
which allows the user to gain security access to the ECARS 2.0 application. The ECARS 2.0 application 
will use the Application Security System to determine whether or not a user has sufficient rights for such 
access. Once security access is gained refer to the use case Menu Security. 

2- Flow of Events 
2.1 Basic Workflow 

2. 1. 1 Use Case Begins 

This use case begins when a user chooses to work with the ECARS 2.0 application. 

2. 1.2 Enter User Credentials 

Ihe^vjtenmromst§ the user to enter a user id an dimswordiji.o rder to gain security access to the ECARS 
2.0 app1icatim_I33ejLiser_enter$ the req uired information . 

2. 1.3 Passing User Information 

The system takes the information entered by the user and passes it to the Application Security System for 
authentication. Tf not enough information was entered see alternate flow Insufficient Information. 

2.14 Receive Authentication Status 

The applicati oj^egjritvsvstem confir ms the user id and password are valid. The user is given access to 
the ECARS 2.Q a pplication . If a valid user id was entered but a valid password was not see alternate flow 
Invalid Password . If the system denies the user access to the application, see alternate flow No Rights To 
Application . If it is time for the user to change their password, call use case Change Password . The user 
can also choose to cancel at any time and the use case ends. If the user selects to cancel, the system will go 
back to the initial splash screen. 

2.1.5 Language Determined 

Upon initial entry to the ECARS 2.0 application fi.e. the user ci fckSJftjg on and is bro u^Uo^JUnitiaLsian 
on screen) the system determines what language the application will disnlayjthis will be determined from 
the browser-h owever, for IterationJL Jm^^Js^ut of scope) . 

2.1.6 E-locale 

Prior to the user going through the security process, the system establishes E-tocale. This is determined 
when the terminal is activated. The follow ing information is obtained during this process: 

• Time zone of user 

• Locale 

• Home mach ine of user 

• Legacy group 

• Legacy branch 

• Peoplesoft group 

• Peoplesoft branch 
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2.1.7 The use case ends 

The user has successfully launched the ECARS 2.0 application and gained security rights to the application 
by entering a valid user id and password. See the Menu Security Use Case for more information regarding 
a user's security rights once in the ECARS 2.0 application. 

2.2 Alternative Workflows 

2. 2. 1 No Rights to Application 

The svstem does not recognize the use ridjadjflssword entered and some type of error message is 
produced . The user can choose to re-enter the information required to get into the application and the use 
case continues at the main flow Initiating Call . If the user does not choose to re-enter the information the 
use case ends. 

2. 2. 2 Invalid Password 

A valid user id was entered but an invalid password was entered and some type of error message is 
produced . The user enters a different password and the use case continues at the main flow Initiating Call . 
The user does not choose to enter a different password and the use case ends. 

2.2.3 Insufficient Information 

QnoLkgflLQf the fie ^ s ^ user i<j and p assword^ required for the system to p ass to the Application Security 
System were missing and some tvoe of error message is produced . The user can choose to re-enter the 
information and the use case continues at the main flow Initiating Call . If the user does not choose to re- 
enter the information the use case ends. t 

2. 2. 4 The use case ends 

3. Special Requirements 

4. Pre-Conditions 

.4.1 The local computer has been logged into 

4.2 ECARS2.0 Application and Secured Objects Registered with Application Security 

This pre-condition assumes that the ECARS2.0 application and its subsequent "Secured" 
objects are registered in the Application Security System. See Supplemental 
Specification: ECARS20 Secured Objects 

5. Postconditions 

5.1 Post-condition One 
6- Extension Points 
6.1 name of extension point 
7. Future Scope 

7.1 E-locale— this will have to be determined based on country and language 
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Business Use-Case Specification: Menu Security 


1. Menu Security 

1.1 Brief Description 

The purpose of this use case is to show what different security rights branch employees have upon access to 
the ECARS 2.0 menu. The three that will be looked at in this use case are 1) car prep and driver, 2) 
management trainee, management assistant, assistant manager and 3) a branch manager. This use case will 
also discuss navigation functionality that the user will be presented with. The navigation will involve 
mouse hover and shortcut key functionalities. 

2. Flow of Events 
2.1 Basic Workflow 

2.1.1 Use Case Begins 

This use case begins when a user chooses to work with the ECARS 2.0 application. The user will have 
already logged on to the initial user id and password screen. 

2.12 Rights Made Available 

Right after the user enters their user id and passw ord, the system makes the application rights status 
associated to the user av ailable at this time . The user may have more or less access rights according to 
their security level. 

2. 13 Branch Employee Security Rights 

A branch employee (management trainee, management assistant, assistant manager) chooses to work with 
the ECARS 2.0 application. If the branch manager chooses to work with the application see alternate flow 
Branch Manager Security Rights . If a car prep or driver chooses to work with the application see alternate 
flow Other Rights. 

2.14 Main Menu Navigation Area 

Upon gaming access to the ECARS 2.0 application the user will see a main menu.. 

2.1.5 Tools, Profile and Help 

The user will see the basic functions of tools, and help on the main menu navigation area. Based on the 
level of the employee what is actually seen within each function may vary. For a branch employee 
(management trainee, management assistant, and assistant manager), their type of security can be seen 
continuing with the flows below. Within these sub-applications, the user will be able to navigate using the 
Control ' ' keys (shortcuts^. 

2.1.6 Tools 

Within Tools the user will see Estimate Total Charges' and 'Reports' as well as "Change Password." 
Please refer to the Change Password Use Case for further information. 

2.17 Help 

Within Help the user will see fi Web ECARS Help' and 'About. 5 
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2.1.8 Reservation, Contracts, Callbacks, and Rates 

The user will see the sub-applications of reservation, callbacks, contracts, and rates on the main menu 
navigation area. Within these sub-applications, the user will be able to navigate using the Control ; ; kevs 
(shortcuts). 

2.19 Mouse-Hover 

The user is a ble to use the mouse to "hover" over each sub -applicatio n and view the different options under 
eack The user can select whicheversu^ work in by clicking on e of the options 

associated to th at sub-application. 

2.1.10 Reservation 

The user chooses to work with the reservation sub-application. If the user chooses to work within the 
callback sub-application see alternate flow Callback. If the user chooses to work within the ticket sub- 
application see alternate flow Ticket If the user chooses to work within the Rates sub-application see 
alternate flow Rates. 

2.1.11 The Use Case Ends 

2.2 Alternative Workflows 

2.2. 1 Branch Manager Security Rights 

The branch manager will have the same rights as those listed in the main flows for the branch employee. In 
addition, the branch manager will also be able to access the rates test window as well as the taxes and 
surcharges functionality and these fall under the Rates sub-application. * 

2.2 2 Rates Sub-Application 

2.2.2. 1 Rates Test Window 

A branch manager should be able to access the rates test window from their security menu. See Rate 
Verification Use Case. 

2.2.2.2 Taxes and Surcharges 

A branch manager should be able to access the taxes and surcharges window from their security menu. 

2.2.3 Contracts 

Once the user selects to work in the contracts sub-application, they can select to search for an open ticket or 
create a new ticket The options of open, edit, and close will be available. 

2.2.3.1 Open, Edit, and Close 

Once the user has selected a ticket, the functions of 'open/ 'edit,' and 'close' become enabled. They can 
also choose to select another sub-application to work with and the use case continues at the Main Menu 
Navigation Area. 

2.2.4 Callbacks 

Once the user selects to work in the callbacks sub-application, they will see Callback Summary and 
Callback Search functionalities. They can also choose to select another sub-application to work with and 
the use case continues at the Main Menu Navigation Area . 

2.2.5 Other Rights 

A car prep and/or driver choose to work with the ECARS 2.0 application. They enter their user name and 
password and are brought to their menu. 

2.2.5.1 Menu of Car Prep/Driver 

The user will have read only rights to reservations. Thev wi ll be able to change their password if 
thevso desire. 
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2.2.6 The use case ends 

3. Special Requirements 

4. Pre-Conditions 

5. Postconditions 

5.1 <Post-condition One> 

6. Extension Points 

6.1 <name of extension point> 

7. Questions 

8. Menu Hot Keys and Shortcuts (a supplementary guide) 

Please see the link A pproved Hot Key Documentation 

9. Future Scope 
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2. Flow of Events 

2.1 Basic Flow 

2.1.1 User selects to Unlock the Application. 

2.1.2 System displays the Lock /Unlock Screen. 

2. 1.3 User enter their credentials (User ID and Password). 

2. 1 4 The system calls the Authenticate User function (User ID, Password, Application) 

2. 1, 5 The system retrieves the History data. 

2. 1 6 The system determines that the user has rights to the records in the History. 

2. 1. 7 The system retrieves the records from the DB. 

2.1.8 The system re-issues the DB lock. 

2. 1. 9 The system sets the session status to Active. 

2. 1. 10 The system displays the last record to the user. 

2.1.11 The use case ends. 

2.2 Alternative Flows 

3. Special Requirements 

4. Pre-Conditions 

4.1 Application was in the Locked state to start. 
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5. Post-Conditions 

5.1 Application Active 

5. 1 1 Application Active and presents the last active record. 

5. 1.2 Application Active and placed at the Main Menu Splash Screen. 

5.2 Application Locked 

5.2 1 User authentication threw an exception. Return to Lock Screen. 

5.2.2 User presented the Mandated Change Password Screen. Successful - Main Menu Splash 
Screen. 

6. Extension Points 

6.1 Errors during Authenticate User 

6. 1 1 Exceptions will be handled by the Authenticate User Use Case. 

6.1.2 Use Case Ends. 

6.2 User does not have rights to the records in the History file. 

6.2. 1 System determines that the user does not have rights to the records in the History file. 

6.2.2 System Displays Main Menu Splash Screen based upon the user's security rights. 

6.2.3 Use Case Ends. 

6.3 User has rights to some of the records in the History file. (Future) 

6.3.1 System determines that the use has rights to at least one but not all the records in the History file. 

6.3.2 System removes the non-valid files from the access list. 

6.3.3 Use case continues with main flow at 2. 1. 7. 
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About ECARS 2,0 Screen Specification: Version 1,0 

1. Introduction 

This document captures the requirements for the About ECARS 2.0 Page. 

2. About Screen 


About ECARS 2.0 - Web Page Dialog 



Build: DEV_CLEAN_200111120917 


This Software contains valuable, confidential, trade secret 
information owned by Enterprise and is protected by copyright 
laws and international copyright treaties, as well as other 
intellectual property laws and treaties. ACCESS TO AND USE OF 
THIS SOFTWARE IS RESTRICTED TO AUTHORIZED EMPLOYEES 
OF ENTERPRISE RENT-A-CAR COMPANY, This Software and any 
data nspri in rnnnprHnrv wii-h.nrJcu^nRr*t"Rd hv r-hk ^nfrwarp 


Pi 




2.1 Title 


The title area dis plays: Abou t ECARS 2.0 - Web Page Dialog 


Screen Shot 


2.2 ECARS 2.0 Sp lash Graphic 

ECARS Splash g ra phic is displayed. 


2.3 Build Version Number 

The system displays the Build/Versi on Number to the User. 
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2.4 Textual inf ormation Area, 

The system displays the Legal Notice: See Sup Spec for Legal Notice, 


2.5 OK Button 

2.5.1 Behavior 

Selecting this button, closes the window. 

2.5.2 Validation 

2. 5. 3 Business Exceptions 
2. 5. 4 System Exceptions 

2.6 Rules 

Navigation: Closing the window, via the X or the OK Button takes the user to the last active 

2.7 Security 

N/A $ 
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Hot Keys for APNS 

1. Introduction 

This document captures the Hot Keys used in the Application Navigation and Security Project 


■JSI R 


m 


I j. 


s. : r' 


2. Loain Screen 
2.1 Login 

2.1.1 English Alt-L 

2.1.2 En GB Alt-L 

2.1.3 En CA Alt-L 

2.1.4 En IE Alt-L 

2.1.5 Fr CA Alt-L 

2.1.6 DE Alt-A 


2.2 Clear 

2.2.1 English Alt-C 

2.2.3 En CA Alt-C 

2.2.4 En IE Alt-C 

2.2.5 Fr CA Alt-C 

2.2.6 DE Alt-L 
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3. Change Password Screen 
3.1 Change Password 

3.1.1 English Alt-P 

3.1.3 En CA Alt-P 

3.1.4 En IE Alt-P 

3.1.5 Fr CA Alt-P 

3.1.6 DE Alt-P 


3.2 Cancel 


3.2.1 Enalish 

Alt-C 

3.2.2 En GB 

Alt-A 

3.2.3 En CA 

Alt-C 

3.2.4 En IE 

Alt-A 

3.2.5 Fr CA 

Alt-C 

3.2.6 DE 

Alt-A 
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4. Mandated Change Pass word Screen 

4.1 Change Pas sword and Login 

4.1.1 English Alt-L 

4.1.2 En GB Alt-L 

4.1.3 En CA Alt-L 

4.1.4 En IE Alt-L 

4.1.5 Fr CA Alt-L 

4.1.6 DE Alt-L 

4.2 Change Pass word and Unlock 

4.2.1 English Alt-P 

4 2 2 En GB Alt-P 

4.2.3 En CA Alt-P 

4.2.4 En IE Alt-P 
42S FrCA Alt-P 
4.2.6 DE Alt-P 

4.3 Cancel 

4.3.1 English Alt-C 

4.3.2 En GB Alt-C 

4.3.3 En CA Alt-C 
4 3 4 En IE Alt-C 

4.3.5 Fr CA Alt-C 
4.3.6 
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5. Lock/Unlock Screen 


5.1.1 Enalish 

Alt-U 

5.1.2 En GB 

Alt-U 

5.1.3 En CA 

Alt-U 

5.1.4 En IE 

Alt-U 

5.1.5 Fr CA 

Alt-U 

5.1.6 DE 

Alt-E 

5.2 Clear 


5.2.1 Enalish 

Alt-C 

5.2.2 En GB 

Alt-C 

5.2.3 En CA 

Alt-C 

5.2.4 En IE 

Alt-C 

5.2.5 Fr CA 

Alt-C 

5.2 6 DE 

Alt-L 
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6. Main Menu 

6.1 Reservation 

6.1.1 English Ctrl-0 

6.1.2 En GB Ctrl-O 

6.1.3 En CA Ctrl-0 

6.1.4 En IE Ctrl-0 

6.1.5 Fr CA Ctrl-0 


6.1.6 DE 


Ctrl-0 


K 9 Tioiratc 

o.z 1 iCKeis 


6.2.1 English 

Cth-T 

6.2.2 En GB 

Cth-T 

6.2.3 En CA 


6.2.4 En IE 

Ctrl-T 

6.2.5 Fr CA 

Ctrl-T 

6.2.6 DE 

Ctrl-T 

6.3 Callbacks 


6.3. 1 English 

Ctrl-K 

6.3.2 En GB 

Ctrl-K 

6.3.3 En CA 

Ctrl-K 

6.3.4 En IE 

Ctrl-K 

6.3.5 Fr CA 

Ctrt-K 

6.3.6 DE 

Ctrl-K 

6.4 Vehicle 


6.4.1 English 

Ctrl-M 

6.4.2 En GB 

Ctri-M 

6.4.3 En CA 

Ctrl-M 

6.4.4 En IE 

Ctrl-M 

6.4.5 Fr CA 

Ctrl-M 

6.4.6 DE 

Ctrl-M 
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6.5 Tools 

6.5.1 English Ctrl-J 

6.5.2 En GB Ctrl-J 

6.5.3 En CA Ctrl-J 

6.5.4 En IE Ctrl-J 

6.5.5 Fr CA Ctrl-J 

6.5.6 DE Ctrl-J 


6.6 Help 


6.6.2 En GB 

F1 

6.6.3 En CA 

F1 

6.6.4 En IE 

Ft 

6.6.5 Fr CA 

F1 

6.6.6 DE 

F1 


6.7 Lock Application 

6.7.1 English F9 

6.7.2 En GB F9 

6.7.3 En CA F9 

6.7.4 En IE F9 

6.7.5 Fr CA F9 

6.7.6 DE F9 

7. Rules 


8. Security 
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Legal Notice Description 

1. introduction 

This document contains the wording used in the legal notice currently used on the Login, 
Unlock, and About Screen in the ECARS 2.0 application. 

2. Screen Print 

N/A 

2.1 Legal Notice 

2. 1 1 Behavior 

When required the following Legal Notice shall be displayed to the user: 

Terms of Use 

This Software contains valuable, confidential trade secret in formation owned bv Enterprise 
Rent-A-Car Company a nd is protec ted bv copyr ight laws and international fcopvright treaties, as 
well as other i ntellectual pro perty laws and treaties. ACCES S TO AND USE OF THIS 
SOFTWARE IS RESTRICTED SOLELY TO AUTHORIZED EMPLOYEES OF 
ENTERPRISE RENT-A-CAR COMPANY AND ITS S UBSIDIARIE S. This Softwa re and anv 
data used in connection with or generated by th is Software mav not be licensed, disclosed or 
used except as authorized in writing bv a duly authorized officer of Enterprise Rent-A-Car 
Company. 

© Unpublis hed. Enterprise Rent-A-Car C ompany. All rights reserved. 

2. 1.2 Validation 

2. 1.3 Business Exceptions 

2.1.4 System Exceptions 

2.2 Rules 

2.3 Security 
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Lock/Unlock Screen Action Specification Version 1,3 

1. Introduction 

This document captures the behavior and navigation requirements for the Lock/Unlock Screen 
for the ECARS2.0 Application. This screen is the implementation of the Application Locking 
Use Case. The Lock/Unlock Screen will be presented to the user when the "Lock Application" 
function has been invoke successfully. 


2- Invoking the Lock Function 

The Lock function is invoked from the Main Menu by selecting the Lock Icon. This function 
can also be invoked when the Idle indicator has reached its pre-defined limit. (Currently set at 
five minutes.) 


/£§ Enterprise* 1 ECAFtS Application - Microsoft Internet Explorer provided by En terprise R ent-a-Car 



fr -— — mmmmmtmm ^^ . , - 

Ihrhis application is strictly for reviewing screen design and should not be used to determine gaps or progress or for reporting bugs or 
Idefects. — ~- - , .. * ■ — — 


2.1 

Upon selection: 
Determines the active records. 
Invokes the complete funetioi 
Set the Logged-In flag to False. 
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Dis plays the Lock/Unlock Screen. 


2.2 Validation 

None. 

2.3 Business E xceptions 

None. 

2.4 System Exceptions 

When the system encounters an error, the error message sh all be displayed awaitinp user input at 
this point the idle time indicator stops. Clearin g the error takes th e user to the screen from 
which the error was generated. 


2-5 Rules 

The Lock Function is avai lable through the "Lock Ico n" on the main menu or using the F9 
function key. * 
This function can also be invoked when the Idle indicator has reached its pre-defined limit. 
Currently, idle timeout is set at five minutes. 

This applic ation for Locki ng/Unlocking the Application should use existing functions within the 

target sub-applications . 

Within Reservation the lock function invokes the Complete Method to save active 

reservations. 

The following is a scenario for the interaction between the application locking and the database 
locking for completing a reservation. (Note: This same type of scenario will need to be repeated 
for each sub-application of Callbacks and Open Ticket.) 
A pplication Lock Record Lock Interaction 

a. If during the time that the User A has reservation 1 23456 open for edit the application locks. 

b. The lock will call the com plete reservation functionality. 

i. If com plete reservation is successful at saving th e reservation the lock on the 
reservation 123456 is removed for User A. 

iL If com plete reservation is not successful an er ror message will be displayed and the 
user must correct anv errors before lock ing the a ppli cation, (note: the idle timeout does 

2.6 Security 

The lock function is not a secured object. This function is available to all users. 
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3. Lock/Unlock Screen 


% E384GG 0110 Enterprise® ECARS Application - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 


The Application is Locked 


The application has been locked by RENTAL REDESIGN 1 . Please 
enter your User ID and Password to unlock the application, 

This Software contains valuable, confidential, trade secret information 
owned by Enterprise and is protected by copyright laws and 
international copyright treaties, as well as other intellectual property 
laws and treaties. ACCESS TO AND USE OF THIS SOFTWARE IS 
RESTRICTED TO AUTHORIZED EMPLOYEES OF ENTERPRISE RENT-A-CAR 
COMPANY. This Software and any data used in connection with or 
generated by this Software may not be disclosed or used except as 
authorized in writing by Enterprise Rent-A-Car Company. Your right to 
use this Software shall terminate automatically immediately upon the 
termination of your employment by Enterprise. 

t 

© Unpublished. Enterprise Rent-A-Car Company. All rights reserved. 

User ID: | " 
Password: | " 


Entries in the User ID and Password fields are case sensitive. 


,v - 

% 

I 
w 

>s<j< 


3.1 Information Message 

3. 1. 1 Behavior 

Dis plays the following Text: "The application has been l ocked bv OJser Name). Please enter 
your User TP and Password to unlock the application 

3.1.2 Validation 
None. 

Business Exceptions 


3.13 
None. 

3. 1.4 
None. 


System Exceptions 
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3.2 Legal Notice 

The System displays the Legal Notice to the User. See Sup Spec for wording of the Legal 
Notice. 

3.3 User ID 

3.3.1 Behavior 

Standard User ID field from Login Screen. 

3.3.2 Validation 
Same as for Log-In. 

3.3.3 Business Exception 
Same as for Log-In. 

3.3. 4 System Exceptions 
None. 


3.4 Password 

U 3.4.1 Behavior 

W Standard Password field from Login Screen. 


3.4.2 Validation 

3.4.3 Business Exceptions 

3.4.4 System Exceptions 

3.5 Unlock 

3.5.1 Behavior 

Invokes the Authenticate User Use Case. 
Retrieves the Recent File Data. 

Determines if the U ser has ri ghts to the r ecords in the Recent Files. 

The following is added for clarification to the interaction between the Unlock Function and the 

Database Locking/Unlocking function for records. 

When User A unlocks the ap plication: 

I If no users u pdate reserva tion 123456 while User A has the application locked then when 
User A unlocks the applic ation thev pu ll reservation 123456 for edit with the updates they 
made prior to locking the application. 

ii. If User B up dated the r eservation a nd saved their updates during the time that User A 
had the app lication locked. User A w ill receive reservation 1 23456 for edit with the updates 
that User B applied. 
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iiL If User B still has reservati on 123456 open for edit whe n User A unlocks their 
application. User A will receive a message that reservation 1 23456 is op e n for edit hv 
another user. 
Retrieves the data. 

Re-establish that the s ystem is active. 
Display recordfs^ as appropriate 


Navigation: 

When the User has the sa me rights as the previous user: The s^ 
screen the previous user was on with the last record as the active record. 


ales to last 


When the User has different rif 
Main Menu with the splash screen 


dous user: The user 


While Authenticate User T Tse Case has c ontrol if an ex ception is thrown redisplay lock 
screen or redirect user to the Mandate d Chang e Pa ssword Screen as ap propriate. Upon 
successful chanpe of Password d isplay the Main Menu with Splash Screen. 

3.5.2 Validation 

Same as for the Log-In Screen element of "Log-In". 

3. 5.3 Business Exceptions 

3.5.4 System Excep tions 

Same as fo r the Authenticate User Use Case- 
Database Locking conf licts to be handled bv the Database Locking UC. 

3.6 Clear 

3.6.1 Behavior 

Clears both the User ID and Passwor d fields and redisplays the screen alon g with the "Locked" 
Message. 

3.6.2 Validation 

3.6.3 Business Exceptions 
3. 6 A System Exceptions 


3.7 Rules 

General: Cursor is placed in the User ID field. Tab 
fight (User Id, tab, Password, tab, OK, tab, Clear.) 

3.8 Security 

This screen is not a secured object. 
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The Unlock function will be available to all users. 
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Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the User Authentication process 
being used for the ECARS2.0 Application. This document will also serve as the starting point for the 
detailed screen design. 

The system must be able to display the proper screen language presentation. This information can be 
obtained from the calling application ECARS2.0 through the use of the language established in the 
browser. 

2. Loq-in Screen 


3 Enterprise^ ECARS Application - Microsoft internet Explorer provided by Enterprise Rent-a-Car 



llllllfjlp http://nd ev0^7001/tental/(x^mljlogOT . u . , . ., 


^2g*m.>\.. _ . _ - . . 


Welcome to ECARS 2.0 

This Software contains valuable, confidential, trade secret information owned by Enterprise 
and is protected by copyright laws and international copyright treaties, as well as other 
intellectual property laws and treaties. ACCESS TO AND USE OF THIS SOFTWARE IS 
RESTRICTED TO AUTHORIZED EMPLOYEES OF ENTERPRISE RENT-A-CAR COMPANY. This 
Software and any data used in connection with or generated by this Software may not be 
disclosed or used except as authorized in writing by Enterprise Rent-A-Car Company. Your 
right to use this Software shall terminate automatically immediately upon the termination of 
your employment by Enterprise. 

© Unpublished. Enterprise Rent-A-Car Company. Ail rights reserved, 

User ID: jj ™~ 
Password: 



Entries in the User ID and Password fields are case sensitive. 


2.1 Le gal Notice 

The Legal Notice is presented to the User. See Sup Spec for wording of the Legal Notice. 
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2.2 User ID Field 


2.2.1 Behavior 

This is an alphanumeric data entry field Minimum length is 6: maximum is to be consistent 

with the Application Security System. What is expected here is "E The "E" will not 

be pre-populated. Items are case sensitive. 

2.2.2 Validation 
None. 

22.3 Business Exceptions 
None. 

2.2.4 System Exceptions 
None. 

2.3 Password Field 

2.3.1 Behavior 

This is an al phanumeric data entry field . Minimum length of 6 with a maximum of 30 . What is 
expected here is the User's password. The dis played informatio n will be masked bv the 
character. The information in this field will also ne ed to be encrypted, as to not allow its 
contents to be viewed through the "View Source" browser option. 

2.3.2 Validation 
None. 

2.3.3 Business Exceptions 
None. 

2.3.4 System Exceptions 
None. 


2.4 Lnqin Button 

2.4.1 Behavior 

This o peration will take the inputs from the User I D and Password fields 
Ap plication Name and invoke the "Authen ticate User" method in the Application Security 

System. 
Navigation: 

- When login is successful, takes the user to the ECARS 2.0 


image displayed. 

When the svstem throws an error, display error in an error message box. 


error takes the user back to the l o ^in screen. 

When the error is the Password Expired Exception Tease where the user must change their 
password to proceed! direct the user to the Change Password Screen with the Password 
Ex pired Error Message displayed. 
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Note: The user can access the Change PW screen by selecting that screen or by Closing 
the Error Message Window. (This is a general note and really applies to all Error 
Message Windows.) 

2.4.2 Validation 

No local validation, Application Security System will use the input for its validation. 

2.4.3 Business Exceptions 
None. 
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2.4.4 System E xceptions 


Throw 

DEF 

Show as Error Message 

1 n va I id 1 n p utExcep tion 

This exception occurs when an 
input parameter is invalid. 
Typically this is generated by 
passing in any kind of null value 
into a required field. 

Insufficient Information 
Entered. Please re-submit 
vour reauest. 

ArchSecurityException 

This exception is the base class for 
any exception that can be thrown 
from the Security Architecture. It 
also can be thrown if an 
unexpected error occurs, such as a 
network problem, database error, 
etc. 

Authentication Failed. Re- 
submit vour request. 

InvalidAuthenticationE 

< • 

xception 

This exception occurs when an 
invalid username or password is 
passed to authenticateUser. 

Invalid User 

Name/PasswoM. Verifvthe 
CAPS LOCK function is 
Off 

NoAccessToAppExcep 
tion 

This exception occurs when the 
user has no access to the 
application. 

Securitv Access Denied. 

Password Expired Exce 
ption 

This exception occurs when the 
user's password is expired. 

Password Expired. Please 
Enter New Password. 

UserLockedOutExcepti 
on 

This exception occurs when the 
user has been locked out of the 
security system. 

You have been locked out of 

vour designated network 
administrator. 


2.5 Clear Button. 

2.5.7 Behavior 

Clears the Values of User ID and Password 

2.5.2 Vaiidation 
None. 

2.5.3 Business Exceptions 
None. 

2.5.4 System Exceptions 
None. 
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2.6 Exiting the Application 

Exiting the amplication can be accomplished bv selecting the "X" in the upper right hand corner 
of the applic ation window. 


0 
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2.7 Rules 

Tab Order: 

The cursor shall be placed in the L o gin Field upon entry to the screen. Tabbin g off the Losi 
field shall change focus to the Password field. Tabbi ng off the Password field shall change 
to the Login button. Tabbing off the Login button shall change focus to the Cancel button. 

No data checking is being performed at the screen level 

2.8 Security 

Passwords shall be encrypted: On screen the typed password shall be masked with the "*" 
character. The user shall not be able to view the plain text password when using the "View 
Source" option in the browser. 
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3. Change Pas sword Screen 


'5 Enterprise* ECARS Application - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 


Change Password 


User ID: E3846G 


Existing Password: [~ 
New Password: 


Confirm New 
Password: 



ft 
!!;'! 

s 

w 


3-1 User ID Field 

3. I f Befcavfe 


Same properties as User ID from Login Screen. Pre-populated with the existing user's ID. 

3.1.2 Validation 
None. 

3.13 Business Exceptions 
None. 

3.1 A System Exceptions 
None. 
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3.2 Existing Pas sword Field 

3.2.1 Behavior 

Same properties as Password field on the Login Screen, 

3.2.2 Validation 
None. 

3.2.3 Business Exceptions 
None. 

3.2.4 System Exceptions 
None. 


3.3 Mew Password Field 

3.3.1 Behavior 

Same pro perties as Password field on the Lo gin Screen. 

3.3.2 Validation 
None. 

3.3.3 Business Exceptions 
None. 

3.3.4 System Exceptions 
None. 

3.4 Confirm New Password Field 

3.4.f Behavior 

Same properties as Password field o n the Login Screen. 

3.4.2 Validation 
None. 

3.4.3 Business Exceptions 
None. 

3.4.4 System Exceptions 
None. 

3 rthanqe Password Button 

3.5.7 Behavior 

This field starts the process to change the User's password in the Application Security System. 
Prior to invoking the "Change Password" function, some validation is done at the screen level. 

A Pase* Last saved: 

S^SnentCase 12*19 12/20/01 4:28 PM 

Path: 

Y:\GROUPS\E-Commerce Group\Patent Materials 831J)l\Copy of All Patents\ECARS20 - Application Navigation & Secunty\Supplemental 

Specs\Login Screen Spec. doc 


Project: 

Application Navigation & 
Security 


Phase: 

Inception 


Iteration: 

N/A 


When the Change Password Function is successful Display the following test m essage on the 
Change Password Scree n: "Your password has been successfully changed!" Navigation off this 
screen is ac com plished through the main menu. 

3.5.2 Validation 

This interface checks that the "New Password" and the "Confirm New Password" fields contain 


the same i nformati< 
Security System for its processing, 

3.5.3 Business Exceptions 
None. 


established th e packet can be sent to the Application 


Throw 

DEF 

Show as Error Message 

Password 
A/fi cm atch 

1Y110J.1AU.LV11 

New Password and Confirm New 
Password do not match. 

The passwords you typed 
do not match. Please re- 
submit vour reauest. 

ArchSecurityExcepti 
on 

This is thrown when an unexpected 
exception occurs 

Authenticatiofi Failed. Re- 
submit vour request. 

InvalidAuthentication 
Exception 

This exception is thrown when either 
the user inputs an invalid username 
or password. 

Invalid User 

Name/Password. VerifVthe 
f!APS T.OCJK function is 
off. 

BadPasswordExcept 
ion 

This exception is thrown if a user 
inputs a new password that is less 
than six characters, longer than 30 
characters, or repeats any of the last 
5 passwords that this user has had 
before. 

Your password must be 
between six and thirty 

must not match one of the 
five previous passwords. 

UserLockedOutExce 
ption 

This exception is thrown when a user 
is locked out of the Security 
Framework. 

Ymi have been locked out 
of the svstem. 
Please contact vour 
designated network 
administrator. 

InvalidlnputExceptio 
n 

This is thrown if any of the input 
strings are null. 

Enter data into all the fields. 

Old password new 
password match 


The new password must not 
match the current 
password. 
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3.6 Cancel Button 

3.6.1 Behavior 

id returns the user to the Main Menu with the splash 



3.6.2 Validation 
None. 

3.6.3 Business Exceptions 
None. 

3.6.4 System Exceptions 

If the Change Password function was enacted from "Conditional Log-On - User Must Change 
Password to Proceed" and Cancel has been select prior to the password being changed 
successfully, the ECARS2.0 Application shall return to the Login Screen. If the Change 
Password ftmction was invoked from the menu, the Cancel will take the user back to the Main 
Menu "Splash" Screen. 

3.7 Rules 

- User ID is pre-populated . U pon entry to the screen, cursor will be positioned in the Existing 
£i Password Field. Tab order: Top to Bottom. Left to Right. New Password and Confirm New 
Password shall be checked to ensure thev are the same prior to sending to the Application 
Security System. This is not a check to ensure the passwords conform to length or repeating 
rules. Those checks are handled by the central security system. 

Passwords shall be encry pted: On s creen the ty ped passw ord shall be masked w ith the "*" 
character. The user shall not be able to view th e plain text password when using the "View 
Source" option in the browser. 


Artifact: Page: Last saved: 

Development Case 14 of 19 12/20/01 4:28 PM 

Path: 

Y:\GROUPS\E-Commerce Group\Patent Materials 8J1 J)l\Copy of All Patents\ECARS20 - Application Navigation & Security\Supplemental 

SpecsXLogin Screen Spec.. doc 


Enterprise 


rent-a-car 



Project: 

Application Navigation & 
Security 


Phase: 

Inception 


Iteration: 

N/A 


4. Mandated Ch ange Password Screen 

This is the Mandated Change Password screen; this screen will he shown when the user must 
change their password to gain entry into the ECARS 2.0 Application. There are currently two 
paths to get to this screen: The primary method is when the user is logging into the system and 
their password is expired and the alternate method is when the user is attempting to unlock the 
application and their password has expired. This case will be referred to as the Variation 1 . 
After the password has been changed successfully, the system automatically invokes the 
Authenticate User (Login) or when invoked from the Unlock Screen the system invokes the 
Unlock System functionality.. Since this screen uses many of the same functions and behaviors 
from the main Change Password Screen, only the differences will be documented as 
requirements. 

Primary Screen Shot: User attempting to login to the systems and their password is expired. 
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Variation 1 : User is attempting to Unlock the application and their password is expired. 


'3E3846G 0101 Enterprise® E CARS Application Microsoft Internet Explorer provided by Enterprise Rent-a-Car 

Change Password 


User ID: |E5396B 

Existing Password: j| 

New Password: 


Confirm New r 
Password: 1 



4.1 User ID 

4.1.1 Behavior 

This is an editable text box. Will he nre-nopnlated with User 
Unlock Screen. 


4.12 Validation 
None. 
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4.13 Business Exceptions 
None. 

4.1 A System Exceptions 
None. 


4.2 Change Password & Log in Button Variation: C hange Password & Unl ock Button 

4.2.1 Behavior 

This field starts the process to ch ange the User's password in the Application Security System. 
Prior to inv oking the "Change P assword" function, validation is do ne at the screen level. 
After the Change Password Function is successful, the system invokes the Login function 
automatically. Variation: After the C han ge Password Funct ion is successful the system 
invokes the Unlock function automatically. Upon successful login the system displays the 
Main Menu with the splash screen. Variation: Successful Unlocking takes the user to the 
appropriate screen as dictated by the Unlock Functi onality. 

4.2.2 Validation * 

During the Change Password portion: Same as for the Change Password Button from the Change 
Password Screen. 

During the Login Portion: Sam e as the Log in Button on the Login Screen. 

Variation: During the Unlock Portion. Same as the Unlock Button on the Unloc k Screen. 

4.2.3 Business Exceptions 

During the Change Password portion Same as fo r the Change Password B utton from the Change 
Password Screen. 

During the Login Po rtion: Same as the Login Button on the Login Screen. 

Variation: During the Unlock Portio n. Same as the Unlock b utton on the Lock/Unlock Screen. 

During the Change Password portio n: Same as for the Change Password Button from the Change 
Password Screen. Closing the error message takes the user back to where this function was 
invoked. 

During the Login Portion : Same as the Login Button on the Login Screen. Closing an error 
message take the user to the Login Screen. 

Variation: During the Unlock Portion. Same as the Unlock Button on the Unlock Screen. 


4.3 Cancel Button 

4.3.1 Behavior 

Once selected, takes the user back to the Login Screen. 

Variation: Once selected, takes the user back to the Lock/Unlock Screen. 
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4.3.2 Validation 
None at this point. 

4.3.3 Business Exceptions 
None. 

4.3.4 System Exceptions 
None. 
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Main Menu Screen Action Specific ation Version 1,10 

1. Introduction 

This document will describe the behavioral characteristics associated with the ECARS2.0 Application 
Menus. This document will also serve as the starting point for the detailed screen design. 

The system must be able to display the proper screen language presentation. This information can be 
obtained from the LOCALE information stored in ELOCATION for the session. 

2. Main Menu Screen 


! 5 | 


Reservation 

Tickets 

Callbacks 

Tools 

Vehicle 

Help 

Detail 

Search 

Summary 

Change 
Password 


Web ECARS 
Help 

Summary 

New 

Search 

Rates Test 
Window 


About 

Forecasting 



Rates and Rules 



Notification 



Reports 
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Search 



Taxes and 
Surchrges 



New 
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2.1 Reservation 


/3 Enterprise^ ECARS Application - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 













2.11 Behavior 

Mouse Over on the Reservation w ill dis play t he following sub-fiim 
Forecast. Notification . Search, and New. 
Selection of Reservation performs the same function as selecting Detail 
Short Cut Kev for Reserv ation is Ctrl a. 

Selecting the Reservation suh-function n avi gates the user to the following Reservation Screen: 
New - Driver Search Screen 
Detail - Reser vation Dailv Activity D etail Screen 
Summary - R eservation S ummary Screen 
Forecasting - Reservation Forecast Screen 
Notification - Reservation Notification Screen 
i - Reservation Search Screen 
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2.12 Validation 

Once on a screen, selection of another function requires at least the minimum information be 
filled in on the current screen, else an error message is displayed. (Note: This is not a function 
of the Main Menu.) 

2.1.3 Business Exceptions 
None. 

2. 1 . 4 System Exceptions 
None at this point. 


Artifact; 

Development Case 


7 of 16 
Path: 


Last saved: 

12/20/01 4:31PM 


Y:\GROUPS\E-Commerce Group\Patent Materials 8_3i_01VCopy of All Patents\ECARS20 - Application Navigation & Security\Supplementai 

Specs\Main Menu Screen Action Spec.doc 


Enteri 

prise 

■ i 

rent-a-car 


Project: 

Application Navigation / 
Security 



Phase: 

Inception 


Iteration: 

N/A 


2.2 Tickets 


/5 Enterprise* ECARS Application ~ Microsoft Internet Explorer provided by Enterprise Rent-a-Car 



2.2.1 Behavior 

Mouse over Tickets display the sub -fanctions: Search and New. 
Selection of Tickets performs the same functio n as selecting Search. 
Short Cut Kev for Tickets is Ctrl t 

rin p the sub-fi mction navi gates the user to the follow ing Ticket Screen: 

Search - Ticket Search Screen 
New - Create a Ticket Screen 

2.2.2 Validation 

Once on a screen, selection of another function requires at least the minimum information be 
filled in on the current screen, else an error message is displayed. (Note: This is not a function 

of the Main Menu.) 
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2. 2. 3 Business Exceptions 
None. 

22.4 System Exceptions 
None at this point. 

2.3 Callbacks 


5 Enterprise** ECARS Application - Microsoft Internet Explorer provided by Enterprise Rent-a-Car BEIB 



2.3.1 Behavior 

Mouse over display the sub-functions: Summary and Search. 

Selection of Callbacks performs the same function as selecting Summary. 

Short Cut Kev for Callbacks is Ctrl k. 

Selecting the sub-function navigates the user to the following Callbacks Screen: 
Summary - Callback Summary Screen 
Search - Callback Search Screen 
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2.3.2 Validation 

Once on a screen, selection of another function requires at least the minimum information be 
filled in on the current screen, else an error message is displayed. (Note: This is not a function 
of the Main Menu.) 

2.3.3 Business Exceptions 
None. 

2.3.4 System Exceptions 
None at this point. 
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2.4 Tools 


3 Enterprise^ ECAR5 Application - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 



2*4.1 Behavior 

Mouse over dis plays the following sub-func tions: Change Password Rates Test Window. Rates 
and Rules . Reports. Taxes and Surcharges. 
Selection of Tools takes the user to the Tools Screen. 
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3 Enteiprise* ECARS Application - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 


Rese^fe-q I Tickets' . } Callbacks Vjfc§il§t^3^^MI»i 


Welcome to Tools 




{please select one of the following options: 

Hchanoe Password 

gates Test Win do w 
jjRates and Rules 
Reports 

Taxes and Surcharges 



vui 

SI,. .J 

Hi ,t 

ViVi 

Vs'A'l 


i 

Sift 


si^^Kev for Toofs S creen is Ctrl i. 

Selecting the snh-ftmction navigates the user to the following Tools Screen; 
Change Password - C han ge Pass word Screen 
Kates Test Window - Rates Test W indow Screen 
Rates and Rules - Rates Rule Maintenance Screen 
Re ports - Reports Selecti on Screen 
Taxes and Su rchar ges - Tax/Surcl 

2.4.2 Validation 

Once on a screen, selection of another function requires at least the minimum information be 
filled in on the current screen, else an error message is displayed. (Note: This is not a function 
of the Main Menu.) 

2. 4. 3 Business Exceptions 
None. 

2. 4. 4 System Exceptions 
None at this point. 
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2.5 Vehicle 

2.5.1 Behavior 

This has been inserted to take the user to the Vehicle Maintenance Sub-Application. 
Mouse over display the sub-functions: 

Selection of Vehicle performs the same function as selecting • 

Short Cut Key for Vehicle is Ctrl m. 

u 

^; 2.5.Z Validation 

Si Once on a screen, selection of another function requires at least the minimum information be 
pj.. filled in on the current screen, else an error message is displayed. (Note: This is not a function 
0 of the Main Menu.) 

^| 2.5.3 Business Exceptions 0 
„' : None. 

j»* 2.5.4 System Exceptions 
|! None at this point. 
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2.6 Mb 


3 Enterprise* ECARS Application - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 



2.6.1 Behavior 

Mouse over dis play the sub-functions: Web 
Selection of Hel p perform s the same fanction as selecting Web ECARS Help. 
Short Cut Ke v for Help is the Fl kev. 

Selecting th e sub-ftmctio ns navigates the user to the following Help Screen. 
Weh RCARS Heln 

About - Direc ts the User to the About EG 
S^About ECA RS 2.0 Scree n A^tjQi 

26.2 Validation 

None at this point, this should be available at all times. 

2 6.3 Business Exceptions 
None. 


Pace- Last saved; 

Artifoct: £2ffiU 12/20/01 4:31 PM 

Development Case Path* 

Y-\GROUPS\E-Commerce Group\Patent Materials 8 JlJ)l\Copy of AUPatents\ECARS20 - Application Navigation & SecurityNSupplemental 

Specs\Main Menu Screen Action Spec..doc 



Enter 

prise 


rent-a-car 


Project: 

Application Navigation / 
Security 


Phase: 

Inception 



2.0 


Iteration: 

N/A 


2. 6. 4 Sysfem Exceptions 
None at this point. 

2.7 Lock Function 

The Lock Functionality is availab le throug h the "Lock" Icon. 

The short-cut kev for the Lock Function is the F9 key. 

The lock function may also be started bv the idle time indicator. 

2.8 General Functions 

2.8.1 Exiting the Application 

Exiting th e application is accomplished bv selecting the X button at the top of the browser. 

2.8.2 Minimizing the Application 
Minimizing 


ion is accomp lished bv selecting the button at the top of the browser. 


2.9 Rules 

2.9.1 Navi gation through the use of arrow kevs: 

Selecting the Control kev takes the user to the Reservation Menu Item» navigation between main 
menu items can be accomplished bv using the left and right arrow kevs. Once foc us is on the 
appropriate main menu item, selection can be accomplished with the "Enter" kev. 

2.9.2 Mouse-Over: 

Mouse o ver on the main menu items displays its as sociated sub-functions. 

2.9.3 System Exception Overall: 

An error message shall be displayed when a link is n ot available . Display "The selected 


2.9.4 


The menu will be displayed based on th e language settin g contained ii 
2.9.5 Usability 

When a menu item b lock gains focus- disp lay color will change indicating the item has focus. 

When th e cursor is placed on a link, the cursor will change to the normal select hand. 

Once inside the system, t he Users ID and Location (Group/Branch) should be displayed in the 
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2.10 Security 

This screen is present ed based upon the user' s "secured objects" listing. These are maintained 
within the Application Security System. Painting of sub-screens and menus, will be based upon 
the users security rights within the particular sub-application. 
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Error Message - Session Already Exists for this 

Browser Instance 

1. Introduction 

This document captures the Error Message generated when the user attempts to open a new 
session on the terminal without opening a new instance of the IE browser. 


2. Screen Print 


-3 Multiple Session Eiioi ■ Microsott internet Exploier piovided by tnterpnse Rcni-a-Cai 



There is a session already open for this browser on this terminal. 
Please use that session or open a new browser. * 


►2« 



2.1 grrnr Message 

2. If 

2.12 Behavior 

When the user attempts to open a new session on the same terminal without opening a new 
instance of the browser, display the following error message: 
"There is a session alr eady open fo r this browse on this terminal. 
Please use t hat session or open a new browser." 

For Informational purposes: This situation can occur when the user attempts to open the active 
session by selecting the window titled "About" and uses the "back" button to navigate to the 
previous page. 
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2.13 Validation 

2.1.4 Business Exceptions 

2. 1. 5 System Exceptions 

2.2 Rules 

2.3 Security 
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Secured Object Listing: ECARS2.0 Program 

1. Introduction 

This document captures the naming convention and names used throughout the ECARS2.0 
Application for its secured objects. The System will interface with the Application Security 
System, which is used to administer and house the listing of secured objects and authorized 
users. 

1.1 Purpose 

To document the naming convention used between ECARS2.0 Application and Application 
Security System. These names will also be used to administer "Security" throughout the 
ECARS2.0 Application. 

1.2 Scope 

Only interface requirements between the ECARS2.0 Application its sub-applications and the 
Application Security System. 

1.3 Definitions, Acronyms and Abbreviations * 

1 3 1 Secured Object - Method of identifying program functionality to which security will be applied. 
This can be the whole application, a sub-application, menu items, a page within the application, 
or even a function on a particular application page. 

1 3 2 Secured Object Rights - Each Secured Object will have associated Rightfs) for the user. The 
domain values are: Create, Read, Update, and Void. It will be the responsibility of each sub- 
application to determine the level of access for each of these values. 

1.4 References 

See Use Case - Launch Application_User Authentication 
Application Security System Java.doc 

User set-up matrix for the Main Menu Security. (See file: secured object matnx.SUF) 

1.5 Overview 

The next section will define the Secured Objects used within the ECARS2.0 Application. 

2. Functionality 

2.1.1 l=CARS2.0 Application 


Application Name (max length 30) 

Application Description (max length 256) 


This is the ECARS2.0 Application with its 
associated sub-applications of: Callbacks, 
Contracts, Reservations, Vehicle, and 
Rates/Rules/Taxes and Surcharges. 
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21.2 ECARS2. 0 sub-applications and Secured Objects Registered with Application Security 
The general naming convention for Secured Objects will be: 

- Sub-Application Name + "J' + Window Name + "J' + Field Name 

- Names are case sensitive. 


Secured Object Name (max length 
200) 


Secured Object Description (max length 256) 


FCATIS 2.0 Main Menu 
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Reservation 

MNU RES 


Main menu heading for the Reservation sub-application. 


MNTT RES NEW 


MNTT RFS DETAIL 


MNTT RES SUM 


MNTT RF.S FORECAST 


MNTT RF.S NOTIFY 


MNTT RF.S SEARCH 


Tickets 

MNU TKT 


MNTT TKT SEARCH 
MNTT TKT NEW 


Enables the user to Create a New Reservation. 
Enables the user to view the Reservation Daily Activity 
Detail Screen. 


Enables the user to view the Reservation Summary 
Screen. 


Enables the user to view the two-week Reservation 
Forecast Screen. 


Enables the user to view the ARMS Reservation Results. 
Enables the user to view the Search Screen. 


Main menu heading for the Ticket sub-application. 


Callbacks 


MNTT CRK SEARCH 


MNTT CBK SUM 


Tools 


MNU TLS 


MNTT TT,S RATF.STESTWIN 


Main menu heading for the Callback sub-application. 


Main menu heading for Tools sub-application. (No 
security needed) 


Enables user access to the Rates Test Window. 
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Enter 

prise 


rent-a-car 



Project: 

Application Navigation/User 
Authentication 


Phase: 

Inception 


Iteration: 

^ N/A 



Application Security System. (No security needed) 



Vehicle 


MNU VHC 

Main menu heading for the Vehicle maintenance sub- 
application. 


Since all uses should have access to "Help" and "Exit" functions, no secured object is associated 


Reservation 

Tickets 

Callbacks 

*Tools 

Vehicle 

*Help 

Detail 

Search 

Summary 

* Change 
Password 


*Web 
ECARS Help 

Summary 

New 

Search 

Rates Test 
Window 


*About 

Forecasting 



Rates and Rules 



Notification 



Reports 



Search 



Tax Surcharge 



New 



* Lock 
Application 




H 

hi 


W 

j a; a, 


• Denotes always present. 

2.2 functional Requirement One> 

[The requirement description.] 

3. Usability 

[This section should include all of those requirements that affect usability. Examples follow: 

• specify the required training time for a normal users and power users to become productive at 
particular operations 

• specify measurable task times for typical tasks, or 

• specify requirements to conform to common usability standards, for example, IBM's CUA standards or 
Microsoft's GUI stamdards] 

3.1 <UsabiIity Requirement One> 

The requirement description. 

• certain parts of the functionality of the system).] 

4. Design Constraints 

Length maximums: 
Application Name: 30 Characters 
Application Name Description: 256 Characters 
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Enter 

prise 

.US 

rent-a-car 



Project: 

Application Navigation/User 
Authentication 


Phase: 

Inception 


Iteration: 

N/A 


Secured Object Name: 200 Characters 
Secured Object Description: 256 Characters 

(These are derived from the limits within the Application Security System.) 

<Design Constraint One> 

[The requirement description.] 

Online User Documentation and Help System Requirements 

[Describes the requirements, if any, for on-line user documentation, help systems, help about notices, etc J 


4.1 


5. 
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Date 

Version 
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Author 

01/02/2001 

1.0 

Started Callback Summary Use Case 
Document 

Douglas Newton 

01/03/2001 

1.1 

Added flows related to back/next and 
update message status controls. 

Mike Meusey 

01/04/2001 

1.2 

Added special conditions and issues to 
consolidate requirements from all other 
callback summarv soecs 

Mike Meusey 

01/05/2001 

1.3 

Added sequence diagrams 

Mike Meusey 

03/20/2001 

1.4 

Changed format to match with the 
standard. Added some missing flows 
from Functional specification. 

Santhosh kumar 

04/11/2001 

1.5 

Minor changes to flows. Added links. 
Formatting changes 

Allison Bruhn 

04/17/2001 

1.6 

Minor changes to flows. Took out 
referrals to panels to reflect more along 
the lines of the business functionality ! 

Allison Bruhn 

04/27/2001 

1.7 

Changes based on User Review. 
Altered table in 2.1 .2 to make more 
understandable; added sentence about 
security in sections where the user is 
viewing contracts and then either has 
the authorization to only view or 
actually perform a callback; added an 
alternate flow for Search Callback; 
changed ALL option to ALL Contacts 
option; added in special requirements 
that the Number of Days Outstanding 
reason would be first rather than name 
(confirming); still need to make the 

ChAA Dili Tr\ »*irvr4 O nnfor 

Duiiets witntn onop, bin- 1 o, ana Kenier 
consistent 

Allison Bruhn 

06/07/2001 

1.8 

Change Special Requirement to Clarify 
the sorting order for Customer List and 
Contact. Original Text: The customer list 
should be sorted alphabetically by the 
contact's last name and then first name, 
with the following exceptions. Change 
To: The customer list should be sorted 
alphabetically. Contact list is sort by last 
name and then first name, with the 
following exceptions 

Pin Koh 
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10/11/01 
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Added Print List flow. 
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Business Use-Case Specification: Callback Summary 


1. Callback Summary 
1.1 Brief Description 

The purpose of this use case is to show what a user (a branch empioyee, call center) 
does to view a branch or group's list of callbacks needing to be performed for a given 
day. The user can select to view callbacks by a selected callback method whereby 
certain callback types are associated. 

2. Flow of Events 

2.1 Baste Workflow 

2.1.1 Use Case Begins 

This use case begins when a user chooses to view callbacks needing to be performed 
for a given day. The system retrieves all incomplete cal lbacks for the default group and 
branch /the default is the arouo and branch wher e the user logged in). If the user 
chooses to view callbacks for another branch within the group, see alternate flow yjew 
different branch . If the user chooses to view callbacks for an entire group, see alternate 
flow view different group . If the system does not retrieve any callbacks, see alternate 
flow no callbacks retrieved . 

2.1.2 Callback Method and Type Information 

The user has the option to select a callback method and callback type associated with 
the selected method. The callback methods and callback types available to the user 
are highlighted in the table below: 


Callback Method 
Manual Callback 

Callback Tvoes Associate with the Method 
There are three types of callbacks associated to a Manual Callback. The 
user is able to select which type of callback to perform. The three types are 
listed below: 

• Shop 
. Bill-To 

• Renter 
• 

Automated, Fax, and 

Consolidated 

Callback 

• The two types of callbacks associated with the 
Automated, Fax, and Consolidated Callbacks are: 

• 

• Shop 

• Bill-To 

• 

Manual Shop 

• Upon entry to the Summary, Manual Shop callback 
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Callback 


appears as the default. The user can either choose to 
look at these callbacks or navigate to a different callback 
method and type. 


2.1.3 Callback Summary 

The system also displays a main ca llback summary that contains information 
r.orres pond in g to the previously selected callb ack method and types. 

? 1 4 Shoo Callback 

The user selects the Manual/Automated/Fax/Consolid ated Shop callback option. The 
system displays a list of shop accounts assigned to contracts having incomplete 
callbacks. For each shop, the following informatio n will he displayed: 

• Shop account name 

• Telephone number 

• Number of calls 

• Number of left messages 

• Customer number 

• Customer address 

The user has the option to print this li st see alternate flow Print List. > 

If the user chooses to select the Manual/Automated/Fax/Consolidate Bill-To see 

alternate flow bill-to callback . If the user chooses to select the Renter callback option, 

see alternate flow renter callback . 

2.1 .5 Selecting A Shop Customer 

The user selects a shoo customer from the list. Only one shoo customer mav be 
selected at a time. The system displays a list of contacts associated with the selected 
shoo customer in the main callback summa ry and the following information is displayed 

• Contact Name 

• Contact Phone Number 

• Number of Calls 

• Number of Left Messages 


If the user chooses the ALLoption see alternate flow ALL Contacts option. 

2.1.6 List of contra cts displayed 

The system dis plays a list of contracts associated w ith the selected shop customer in 
the main callback summary. For each conta ct the following information will be 
displayed: 

• Number of days callback h as heen outstanding 

• Renter name 

• Description of renter's vehicle 

• Claim number, policy number. RQ num her. PQ number 

• Date of loss 

• Primary callback reason 

• Today's action of callback 
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• Contract number 

The user will e ither have th e authority to vi ew only or actually perform a callback at this 
point (TBD). 

2.1 .7 The use selects to exit the callback summary and the use case ends. 

2.2 Alternative Workflows 

2.2.1 Rill-To callback 

The user selects the Manua!/Automated/F ax/Consolidateri Biil-To callback option. The 
system displays a list of bill-to customers assigned to contracts having incomplete 
callbacks . 

2.2.2 Selecting a bill-to 

The user selects a bill-to customer from t he list. Only one bill-to mav be selected at a 
time. The system displays a list of contacts associate d with the selected shop customer 
in the main callback summary and the following information is displayed: 

• Contact Name 

• Contact Phone Number 

• Number of Calls * 

• Number of Left Messages 

The user has the option to print this list see altern ate flow Print List. 

If the user chooses the ALL option see alternate flow ALL Contacts option. 

2.2.3 List of contracts displayed 

The system displays a list of contracts associated with the selected hill-to customer in 
the main callback summary. For each c ontract, the following information will be 
displayed: 

• Number of da ys callback hag heen outstanding 

• Renter name 

• Descri ption of Renter's Vehicle 

• Primary callback reason 

• Claim numb er, policy number. PO nu mher. RQ number 

• Date of Loss 

• Today's action on callback 

• Contract Number 

The user will either have the authority to view only or actually perform a callback at tnis 
point (TBD). 

2.2.4 Renter callback 

The user selects the Renter callba ck option . 

2.2.5 List of contracts displayed 

The system displays a list of the renters assigned to extracts that have incomplete 
callbacks. For each contract, the follow ing information is displayed: 
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• Number of d ays the call back has been outstanding 

• Renter name 

• Current amount due (balance due as of estimat ed return date) 

• Pa yment type 

• Renter's home phone number 

• Primary callback reason 

• Contract Number 

• Today's action on last callback 

The user has the option to print this list, see alter nate flow Print List. 

The user will either have the authority to view only or actua lly perform a callback at this 

point (TBD). 

2.2.6 View different branch 

The user chooses to view callbacks for another b ranch within the group . 

2.2.7 View Different Group 

The user chooses to view callbacks for a diff erent group . 

2.2.8 No Callbacks Retrieved f 

The system does not retrieve anv callb acks for a given group branch The user can 
choose to vi ew callbacks at another gro u p branch or chooses to e*it the summary and 
the use case ends. 

2.2.9 ALL Contacts Option 

The user selects ALL in r egards to th e contacts for the selected customer. The 
followin g information will dis play: 

• The contact name will be ALL 

• The contact phone number will be the same a s the customer's 

• The number of calls and m essa ges will h e the sum of the values for all the 
customer's o ther contacts 

2.2.10 Print List 

• The user has the option to print the list they are viewing , 

• The user chooses to print and the use case conti nues at basic flow . 

2.2.11 UNKNOWN contact 

The user selects UNKNOWN in regards to th e contacts for the selected customer. The 
following information will dispiav~ 

• The contact phone number will be th fi same as the customer's 

2.2.12 Perform callback 

If the user se lects to perform a callback, see Shop/Bill-To/Renter perform callback use 
case according to the current select ion of the callback type . 

2.2.1 3 Search for a callback 

If the user selects to search for a callback, see Shop/Bill-Tn/Renter search callback use 
case according to the current selection of the callback type. 
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2.2.14 The user chooses to exit the callback summary and the use case ends. 

3. Special Requirements 

3.1 Alphabetically sorted 

The customer list should be sorte d al phabetically. 

Contact list is sort bv last name and then first name, with the following exceptions: 

• The ALL selection sho uld a ppear first in the list 

• The UNKNOWN contact, if present, s hould appear after the ALL 

3.2 Title Bar 

The title bar displays the callback method and the ca llback type selected on the 
navi gation bar. When the callback summ ary initially comes up, the default 
setting is "manual callbacks - shoo". 

3.3 Callback Center 

When the requesting terminal is from a Callback Cent er, those callbacks that are 
consolidated to the particular Center should be grouped to the appropriate 
callback type under the "manual" callba ck method. 

3.4 Consolidated Callbacks 

Additional data field is shown for the Group and Branc h to wNch the callback is 
consolidated. 

4. Pre-Conditions 

4. 1 The user has logged in and has callback summary view privilege. 

5. Extension Points 

5.1 <name of extension point> 

6. FAQ's 

7. To Be Determined 
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1. Generate Callback List 
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2.1 Basic Workflow 
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Use Case Specification: Generate Callback List 


1. Generate CaHback List 
1.1 Brief Description 

This use case will show what the system does to generate callbacks that result from 
newly created or updated contract information into the Rental GUI. 

2. Flow of Events 

2.1 Basic Workflow 
2. 1. 1 Use Case Begins 

This use case begins when the system generates callbacks based on reasons when 
rental records are created or changed. The types of callbacks that may be generated 
include Shop, Bill-To, and Renter. Since in the callback summary use case, the main 
flow is Shop callback, this use case will stay consistent with that. If the system 
generates a Bill-To callback see alternate flow Generate Bill-To. If the system 
generates a Renter callback see alternate flow Generate Renter . If the Shop is also the 
only Bill-To on the contract, see alternate flow Shoo Is The Bill-To . If the contract status 
is "void" see alternate flow Contract Status is Void . 

2.12 Generate Shnn Callbacks 

A shoo callback is generated with the reason to "Obt ain Repair Status" if the following 
conditions below exists: 

• Fstimated completion date is not null and the contract status is open. 
OR 

• Bill-to exten sion date is not empty a nd the contract status is open. 
Callback date is the earlier of estimated completion date and bill-to extension 
date 

2. 1.3 The use case ends. 
2.2 Alternative W orkflows 

2.2.1 Generate Bill-To Callbacks 

A bill-to callback can be generated based on two reasons. The reasons are obtain 
initial authorization and obtain authorization extension. If the conditions within each 
reason exist, a bill-to callback will be generated: 

2.2.1.1 Reason One-Obtain Init ial Authorization 

• The bill-to authorization is nendino or nu ll and the contract status is 
reservation, open, or close-pended. 

OR 

• The bill-to extension date is null or bla nk and the contract status is 
reservation, open, or close-pended 

Callback date is the date when bill-to is created or changed. 
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2.2.1.2 Reason Two-Obtain Auth orization Extension 

• Bili-To authorization status is Authorized. Bill-To ex tension date is not null 
AND 

• The contract status is op en or close-oended. 
Callback date is the extension date. 

2.2.2 Generate Renter Callbacks 

A renter callback can be generated based on five reasons. The reasons are last day 
notification, balance due, past estimated return date, ticket re-write, or maximum 
authorized amount reached. If the conditions within any of the reasons exist, a renter 
callback will be generated: 


2.2.2.1 Reason One-Last Dav Notification 

. If a value has been entered in to the Bill-To last dav date and the contract 
status is open 
MB 

• Renter has not been con tacted about this last da> 
Callback date is last day date 


2.2.2.2 Reason Two-Balance Due 

• if the renter balance due amount is gr eater than any/ail deposits plus credit 
card autho rizations 

AND 

• the contract status is open or cios e-pended. 

Callback date is 1 day before the date when renter has a balance due. 

2.2.2.3 Reason Threa -Past Estimated Return Date 

• If contract status is open. 
Callback date is estimated return date. 

2.2.2.4 Reason Four-Tioket Rewrite 

• f If the estimated return date minus the co ntract open date is hetween 27 and 
30 davs 

AND 

• The renter has not been notified for rewrite 
AND 

• the contract status is open.) 

• Hfthe estimated return date minus the contract open date is greater than or 
eoual to 31 davs 

• AND 
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• The contract status is open.) 
Callback date is estimated return date. 


2.2.2.5 Reason Five-Maximum Authorized Amo unt Reached 

• If the estimated charges for the Bill-To portion has reached th e maximum 
amount that the Bill-to authorized 

AND 

• The contract status is open. 

Callback date is date when estimated charges exceeds bill-to authorized amount. 


2.2.3 Shop Is The Bill-To 

If the shop is also the onlv bill-to on a contract, a shoo callback and bill-to callback is 
generated. 

2.2.4 Contract Status is Void 

The system deletes all callback records for this reservation and the use case ends. 

3. Special Req uirements 

3.1 Balance Due Threshold 

The value in this field will be used to determine the maximum dollar am ount a renter can 
owe before triggering a callback. Each gro up branch will he able to set the value placed into 
this field for the balance due callback reason onlv. In itially this value will be set to $1 for the 
balance due callback reason for all branches 

3.2 Monday Slid e Threshold 

This threshold acts as a weekend slide but will be set up for every day of the 
week. The value in the threshold indicates th e number of davs later (a positive 
number! or earlier (a negative number) the callba ck should be generated. Each 
branch will be able to set this value for all t he callback reasons. Initially this 
value will be set to: 

• -3 davs=for balance due and maximum authoriz ed amount callback reasons 

• 0 davs=for all other callback reasons 

3.3 Tuesday Slide through Saturday Slide Thresholds 

These will all behave the same way as the Monday Slide. Each branch will be 
able to set this value for all callback reasons. Initially this value will be set to 0 
days. 

3.4 Sunday Slide Threshold 

Same as the Monday Slide. Each branch w ill be able to this value for all callback reasons. 
Initially this value will be set to: 

• -2 davs=for balance due and maximum authorized amoun t tailback reasons 

• 0 davs=for all other callback reasons 
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3.5 Holiday Slide Threshold 

• If a callback would be generated on holiday, then the system will look to the 
value in this threshold to determine how many days earlier (a negative 
number) or later (a positive number) the callback should be generated: 

• -1=for all callback reasons 

3.6 When to Gen erate Threshold 

• This field will tell the system how many davs before a genera tion criteria is 
true to generate the callback. Each branch will be able to set t his value for 
each callback reason. Initially this value will be set to: 

• 1 dav=For balance due and maximum authorize d amount callback reasons 

• 0 davs=for all other callback reasons 

3.7 Contract Stat us Threshold 

• This field indicates the valid statuses of rental contract for a c allback reason. 
Each branch will be able to set this value for each callba ck reason. Initially 
this value will be set to: 

• Reservation. Open. Close-Pend=for initial authorization 

• Open and Close-Pend=for authorization extensio n and balance due callback 
reason 

• Qpen=for all other callback reasons 

3.8 Rewrite Max Davs Threshold 

This field will tell the system the maximum number of davs a contract can be 
opened before a rewrite is necessary. Each branch will be able to set this value 
for a callback reason of ticket rewrite onlv. Initially t his value will be set to 30 
da ys for the ticket rewrite callback reason for all b ranches. 

3.9 Rewrite Minimum Davs Threshold 

This field will tell the system the number of davs before the maxim um is reached that a 
callback reason of ticket rewrite should be generate d. Each branch will be able to set this 
value for a callba ck reason of ticket rewrite onlv. Initially this value will be set to 3 days 
for the ticket rewrite callback reason f or all branches 

3.10 ARMS Callback 

The system reads the ARMS legacy database ARMSPR1 . using the ARMS 
customer profile ID associated as Bill-To/Shop . The Bill-to profile ID always 
overrides Shoo profile ID. The system checks the fie ld value for 'P1YN21' is 
populated as 'Y'. If it is 'Y'. generate the Shop and Bill-T n nallhacks one dav 
before the branch generation criteria would generate it. 

3.11 RMS Callback 

A RMS callback is generat ed hased on the Callback Date . 

• The initial Callback Date i s determined bv the Bill To 
branch num ber, which is stored in the Davs to Call file, 

• The second Callback Date is driven man ually bv the user for all additional calls 
that are made to the body shoo. 
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The system checks in the leaacv database CB032P for the callback date. 

If the callback date is not found, the system checks the CBQ30P file for Davs to 

call, for the Bill-To Account Number. 

3.12 Callback Methods 

By default all callbacks are assigned with Manual method. Below is the rule that 
is applicable for Shoo and Bill-To callbacks: 

• Manual (default method) 

• Electronic 

• Fax 

• Consolidated 

4. Pre-Conditions 

4. 1. 1 First Pre-Condition 

5. Extension Points 
5.1 First extension point 

6. FAQ's 
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Use Case Specification: RMS Callback Summary 


1. RMS Callback Summary 

1.1 Brief Description 

This use case will describe how a user interacts with a system to view a branch or group's list of RMS 
callbacks needing to be performed for a given day. 

2, Flow of Events 

2.1 Basic Flow 

2.1.1 The use case begins when the user chooses to view RMS callbac ks, from th e summary screen, 
needing to be performed for a given day. 

2.1.2 The system retrieves all incom plete RMS callbac ks for the default group and branch (the default is 
the group and branch where the user logged in) . Note: A user may also view callbacks from various 
groups and branches depending on authority. 

2.1.3 The user has the option to view RMS call backs bv: 

• Direct Bill (Y) Tickets o nly (Body sho p calls only) 

• Direct Bill ( Y) Tickets only (ARMS Aut o Body Shop Calls only) 

• Direct Bill (N) Tickets onlv (Authoriz ations needed) 

• Direct Bill fiSD Reservation only (Authorizatio ns needed) t 

2. 1 .4 For the basic flow, the user selects to view Direct Bill fY) Tickets only (Body shop calls only). 

2.1.5 The user selects which RMS account they wish to view . 

2.1.6 The system dis plays a list of shoo accounts assigned to contract s or reservations that have 
incomplete RMS callbacks . For each sho p, the followin g informati on will be displayed: 

• Sho p acco unt name 

• Tele phone number 

• Number of calls 

• Number of left messages 

• Account Number 

• Account Address 

2.17 The user selects a shoo account from the list 

2.1.8 The system displays a list of contacts associated with the selected shop account: 

• Contact Name 

• Contact Phone Number 

• Number of calls 

• Update message status 

2.1.9 The user selects a contact and the system displays a list of co ntracts associated with the selected 
account nu mber in the m ain callbac k summary . For each contract, the following information will be 
displayed: 

• Number of days callback has been outstanding 

• Renter Name 
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Description of renter's vehicle 

Claim Number. Policy Number, RO Number, PO Number 
Date of loss 
Contract status 
Primary callback reason 
Today's action of callback 


Contract Number 
2.1.10 The user se lects from the list of contr acts and the use case ends . 

2.2 Alternative Flows 

2.3 Direct Bill (Y ) Tickets only (ARMS Auto body shop calls! 


2.3. 1 The user selects to view Direct Bill m Tickets only (ARMS Auto body shoo calls). 

2.3.2 The user se lects whic h RMS acco unt the y wish to view . 

2.3.3 The system displays a list of shoo accounts assigned to contracts or reservations that have 
incomplete RMS callbacks . For each account the following information will be displayed: 

• Shop account name 

• Telephone number 

• Number of calls 



• Account Number 

• Account Address 

2.3.4 The user selects a Shop account from the lis 

2.3.5 The system displays a list of contacts associated with the selected Shop account: 

Contact Name 
Contact Phone Number 
Number of calls 
Number of left messages 
Update Message Status 

2.3.6 The user selects a contact and the system displays a list of contracts associated with the selected 
account number in the main callback summary . For each contract the following information will be 
displayed:. 

Number of days callback has been outstanding 
Renter Name 

Description of renter's vehicle 
Claim Number. Policy Number. RQ Number, P( 
Date of loss 
Contract status 
Primary callback reason 
Today's action of callback 
Contract Number 
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2.3.7 The user selects from the list of contrac ts and the use case ends . 

2.4 Direct Bill (N) Tickets only ( Authori sation Needed) 

2A1 The user sel ects to view Direct Bill (H) Tickets on ly (Authorizations needed). 

2.4.2 The system displays a list of Bill T o account s assigned to contracts or reservations that have 
incomplete R MS callbacks . For each account, the following information will be displayed; 

• Bill To account name 

• Telephone number 

• Number of calls 

• Number of left messages 

• Account Number 

• Account Address 

2.4.3 The user sele cts a Bill To account from the list 

2A4 The system displays a list of contacts associated with the selected Bill To account : 

• Contact Name 

• Contact Phone Number 

• Number of calls 

• Number of left messages 

• Update Message status 

2.4.5 The user selects a contact and t he system displays a list of contracts associated with the selected 
account number in the main callback summary . For each contract, the following information will be 
displayed: 

• Number of davs callback has been outstanding 

• Renter Name 

• Description of renter's vehicle 

• Claim Number. Policy Number, RO Number. PQ Number 

• Date of loss 

• Contract status 

• Primary callback reason 

• Today's action of callback 

• Contract Number 

2.4.6 The user selects from the list of contracts and the use case ends. 

2.5 Direct Bill ( N) Reserv ation Only f Authorization Needed! 

2.5.1 The user selects to view Direct Bill (H) Reservation Only (Authorization Needed). 

2.5.2 The system dis plays a list of Bill To accounts assigned to contracts or reservations that have 
incomplete RMS callbacks . For each acco unt, the following information will be displayed: 

• Bill To account name 

• Telephone number 

• Number of calls 

• Number of left messages 

• Account Number 

• Account Address 
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2.5.3 The user selects a Bill To account from the list. 

2.5.4 The system displays a list of contacts associated with the selecte d Bill To account: 

• Contact Name 

• Contact Phon e Number 

• Number of calls 

• Number of left messages 

• U pdate Message Status 

2.5.5 The user selects a co ntact and the system d ispla ys a list of contrac ts associated with th e selected 
account number in the main callback summary . For each co ntract, the following information will be 
displayed: 

• Number of days callback has been outstanding 

• Renter Name 

• Descriptio n of rente r's vehicle 

• Claim Number, Policy Number. RO Number. PO Number 

• Date of loss 

• Contract status 

• Primary callback reason * 

• Today's action of callback 

• Contract Number 

2.5.6 The user selects from the list of contracts and the use case ends . 

General Rule Sets 

1. An unauthorized user will have limited access to RMS callbacks. 

2. RMS callbacks are sorted bv account bv body shop. 

3. Reservations should not dis play after 30 davs . 

4. A bill to Account Number and GPBR Number identifies RMS callbacks . 

5. Closed contracts sho uld not dis play . 

6. Must have the ability to sort calls bv bill to "Y" and "N" for both reservations and 
o pen tickets. 

7. Must dis play whether the contract is ARMS and authorized (direc t bill "Y" or "N"\ 

8. Within the c ustomer profile. RMS calls must be consolidated bv groupf to a 
particular branch. The consolidated groups and branch must be eas ily identified and 
displayed. 

9. An open ticket or reservation must have a bill-to account number (en tered in the 
customer profile) with adjuster callbacks selected, for it to be considered a RMS 
callback. 

4. International Requirements 

5. Pre-Conditions 

• A user has successfully logged onto the computer. 
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• User is an authorized RMS user. 

• Callback is an RMS Callback. 

6. Post-Conditions 

7. Extension Points 

8. Questions 

1 . Does callback date need to be on summary or just perform? 

2. Does there need to be the ability to just select by Direct Bill (Y) etc. or do they 
need to be sorted by this criteria? 

3 . Does the RMS user do the renter calls or is this the branch responsibility? 
4. 
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1. Introduction 

This document details the scenarios in which a callback gets automatically generated. It 
is supplemental information to the Generate Callback Use Case. 

General Information 

• Within this document the callback date is defined as the date to perform the 
callback and is determined differently by each rule. 

• Callbacks will never be generated for a past date. The minimum date that a 
callback can occur is the current date. 

1.1 Purpose 

The purpose of this document is foster the communication between the business users 
and the Callbacks team. It is to be used to put specific examples to items in the use case 
to enhance the clarity of the business rules. 

1.2 Scope 

This document supports the Generate Callback Use Case. 

1.3 References 

Generate Callback Use Case 

1.4 Overview 

The main content of this document documents in detail the business rule that governs the 
life cycle of all callbacks. It describes the conditions, actions and results that affect 
callbacks. 
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Supplementary Specification 

1 . Introduction 

This document details the print requirements for the Callback Summary screens. It is inclusive 
of all methods of callbacks including: Manual, Automated, Fax and RMS. It is also inclusive of 
the types of callbacks including: Shop, Bill-To and Renter. 


2. Print Dialog Box 

When the user selects to orint. the system will disnlav the Internet Explorer standard print dialog 
box. This dialog box does not have anv Hot Kevs and the OK button is the default button. 



Figure 1: Standard Internet Explorer Print Dialog 
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3. Callback Summary Screen 


As specified in the Callback Summary Screen Action Specification, the user will have the 
opportunity to print at any time. If there is more than one table that could potentially be printed, 
the system will provide the user with a pop-up to select the report to be printed. 

The data that the user is looking at will determine what information is printed. For example, if 
the user is viewing Manual. Bill-To callbacks for Group/Branch 01 PL presses the Print List 
button and selects to print the Account list on the Callback Summary Print Dialog , then the 
system will p rint the ' Account List' for Manual. Bill-To callbacks for 01 01 in the format 
specified below . 

There are four different types of tables that the user might print - Account. Contact. Contract and 
Renter. Each of these tables corresponds to a dif ferent report. 

rinted reports will follow the standard report standards including col 


font stvle and size. 

To me( 
bv 1 1 sized paper. 


>le to be ppi 


All re port data will be sorted alphabetically according to the left most field on the report. In the 
situations where a person's name is the left most field, the da ta will be sorted bv last name. 

The re port header data, including the column headers will be repeated at the top of evei 
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3.1 Account List 

This re port prints the following pieces of data for the selected Callback method, type, grout) and 
branch: 

• Name * 

• Phone Number 

• Number of Calls 

• Left Messages 

• Account Number 

• Address 

This report will include a header that informs the user of t he type of callback, the selected 
group/branch and the date/time. 

For RMS callbacks the group/branch in the header will be the terminal location that the user is 
log ged in at. As shown in the example report below. RMS Shop Callba cks will also include the 
selected RMS Customer. RMS Bill-To Callbacks will not have this field . 

RMS Callbacks have a method of Manual except for the ARMS Auto type of callbacks and 
then the method is Automated . 

Examples of the Standard Account and RMS Shop Account List reports are items Al and A2 in 
the appendix 


Confidential 


©Enterprise Rent-A-Car ? 
2000 


Page 6 



Version: 1.2 

ECARS 2.0 

Date: 12/21/01 

Callback Summary Print 


3.2 Contact List 

This re port prints the following pieces of data for the selected Callback method, type, grout), 
branch and account: 

• Name 

• Phone Number 

• Number of Calls 

• Left Messages 

This re port will include a header that informs the user of the t vpe of callback, the selected 
grou p/branch, the selected account and the date/time . 

For RMS callbacks the group/branch in the header will be the terminal l ocation that the user is 
logged in at. As shown in the exampl e re port belo w. RMS Shop Callbacks will also include the 
selected RMS Customer. RMS Bill-To Callbacks will not have this field. 

RMS Callb acks have a me thod of Manual except for the ARMS Auto tvpe of callbacks and 

Examples of the Standard Contact and RMS Shop Contact List reports areltems A3 and A4 in 
the appendix 
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3.3 Contract List 


This report prints the following nieces of data for the selected Callback method tvne» grout). 
branch and contact: 
Name 

Contract Status 
Vehicle 

Claim/Pol/PO/RO 
Date of Loss 
Primary Reason 
Today's Action 
Davs Outstanding 
Group/Branch 


This report will include a header that informs the user of the type of callback, the selected 
ich and the date/time. 

[Scallbacks the group/branch in the header will be the terminal location that the user is 
logged in at. As shown in the example report below. RMS S ho p Callbacks will also include the 
selected RMS Customer. RMS Bill-To Callbacks will not have this field. 

RMS Callbacks have a method of Manual except for the ARMS Auto type of ca llbacks and 
then the met hod is Automated. 

Examples of the Standard Contract and RMS Shop Contract List reports are items A5 and A6 
in the appendix 

Tf the user ha s selected 'All' contacts in the contacts table, the Contract report is slightly 
different. The report will print all of the contracts, grouping them by contact name. There will 
be a page break between contacts. It will follow the same format as th e standard contract. 

Examples of the Standard Account and RMS Shop Account List with All Contacts Selected 
reports are items A7 and A8 in the appendix 
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3.4 Renter List 

This report prints the following pieces of data for the selected Callback method, type, group and 
branch: 


• 

Name 

• 

Contract Status 

• 

Current Amount Due 

• 

Pavment Tvne 

• 

Home Phone Number 

• - 

Primary Reason 

• 

Today's Action 

• 

Davs Outstanding 

• 

Contract Number 


This report will include a header that informs the user of the type of callb ack, the selected 
groun/branch and the date/time. 

This report does not apply to RMS Callbacks. # 
An Example of the Renter List report is item A9 in the appendix 
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Appendix A 

Callback Summary Report Examples 
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Al. Standard Account List 




Callback Account List 



Callback Type: 

Bill-To 

Group/Branch: 

0101 - Ladue 

Callback Method: 

Manual 

Date/Time: 


11/2/2001 11:52 A 



Number of 

Left 

Account 


Name 

Phone Number 

Calls 

Messages 

Number 

Address 

AAA Insurance 

314-555-1111 

2 

0 

AAA1010 

1 Maple Street 






Ave. 

Allstate Ins 

314-555-6666 

1 

2 

ALL0101 

3 Elm Avenue 

My Insurance Co 

314-555-1010 

10 

10 

MIC0101 

6 Cherry Lane 

Other Insurance 

Co£I 

636-555-1111 

12 

12 

OTH01011 

4 Edgar Road 

Soffite Guy's Ins. 

636-555-7070 

2 

2 

SGI1010 

5 Glendale 

Stle Farm Ins. 

314-555-9119 

0 

0 

STF0100 

2 Main Street 

m • 

\\ 




* 



m 

ill 

m 

M. 
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A2. RMS-Shop Account List 



Callback Account List 



Callback Type: 
Callback Method: 
RMS Customer: 

RMS - Shop 
Manual 

STF0101 - State Farm 

Group/Branch: 
Date/Time: 

0101-Ladue 
11/2/2001 11:52A 

Name 

Phone Number of 
Number Calls 

Left Messages 

Account 
Number 

Address 

Bob's Auto Body 

314-555-1111 2 

0 

BAB1010 

1 Maple Street Ave. 

Carl's Cars 

314-555-6666 1 

2 

CC0101 

3 Elm Avenue 

Davis Brothers 

314-555-1010 10 

10 

DBA0101 

6 Cherry Lane 

GdSrge Incorporated 

636-555-1111 12 

12 

GEI01011 

4 Edgar Road 

Soilfe Guy's Fix-It 

636-555-7070 2 

2 

SGF1010 

5 Glendale 

Zafi^r Auto Body. 

314-555-9119 0 

0 

ZAB0100 

2 Main Street 

VI- 

-■IT 

yi 



* 



2; 


la*?. 
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A3. Standard Contact List 



Callback Contact List 


Callback Type: 
Callback Method: 
Account: 

Bill-To 
Manual 

STF0101- State Farm 


Group/Branch: 
Date/Time: 

0101 -Ladue 
11/2/2001 11:52 A 

Name 

Phone 
Number 

Number of Calls 

Left Messages 

Mary Adams 

314-555- 
9090 

3 


2 

Mike Brady 

314-555- 
0009 

2 


0 

Zxfijm 

Niigfle Jones 

j W a, 



314-555- 
1020 

0 


0 

Jof|Kuebler 

.ill 

636-555- 
0101 ext 3 

2 


1 

Saiiantha Peters 

V|. 

314-555- 
6432 ext 10 

1 



JofM Smith 

Si 

— L — 

636-555- 
1212 

0 


0 

A4# Warren 

JjiS: Vi 

3 1 ii 

314-555- 
7867 ext 100 

2 


1 


!«?« 
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A4. RMS-Shop Contact List 



Callback Contact List 


Callback Type: 
Callback Method: 
RMS Account: 
Account: 

RMS - Shop Group/Branch: 
Manual Date/Time: 
STF01 01 - State Farm 
BAB0101 - Bob's Auto Body 

0101-Ladue 
11/2/2001 11:52A 

Name 

Phone 
Number 

Number of Calls 

Left Messages 

Mary Adams 

314-555- 
9090 

3 

2 

Mite Brady 

314-555- 
0009 

2 

0 

NiSdle Jones 

314-555- 
1020 

0 

0 

Jol'fCuebler 

636-555- 
0101 ext3 

2 

1 

* 

Saf||antha Peters 

314-555- 
6432 ext 10 

1 

0 

Jolpa Smith 

in ■ 

636-555- 
1212 

0 

0 

Arif Warren 

314-555- 
7867 ext 100 

2 

1 
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A5. Standard Contract List 


Callback Contract List 


Bill-To Group/Branch: 0101-Ladue 

Manual Date/Time: 11/2/2001 11:52 A 

STF01 01 -State Farm Contact: Mary Adams 

Phone: 314-555-9090 


Name 

Stat. 

Vehicle 

Claim/Pol 
/PO/RO 

Date of 
Loss 

Primary 
Reason 

Today's 
Action 

Day 
s 

Out. 

Group 
/Branch 

John Doe 

O 

Ford 

101010 

10/20/200 

Auth Ext. 

Left 

2 

0102 

» . 


Escort 


1 


Message 



DapEgleston 

\8».eL 

0 

Honda 
Civic 

393939 

11/02/200 
1 

InitAuth 

No 

Answer 

0 

0101 

Ja|lps Farwig 

0 

VW 

2 

09/02/200 

Auth Ext. 


10 

0103 



Jetta 


1 





Julie Loft 

CP 

BMW 

20929 

10/31/200 

Auth Ext. 

i 

2 

0124 



320i 


1 





Riblard Smith 

R 

Honda 

la021 

11/01/200 

Init Auth 

Will 

1 

0115 

?! 

in 


Prelude 


1 


Call 
Back 




It? 

hi 


Callback Type: 
Callback Method: 
Account: 
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A6. RMS-Shop Contract List 


Callback Contract List 


Callback Type: 
Callback Method: 
RMS Account: 


RMS - Shop 
Manual 

STF0101 - State Farm 


Group/Branch: 

Date/Time: 

Contact: 


0101-Ladue 
11/2/2001 11:52A 
Mary Adams 





Claim/P 




Day 


Name 

Stat. 

Vehicle 

ol 

/PO/RO 

Date of 
Loss 

Primary 
Reason 

Today's 
Action 

s 

Out. 

Group 
/Branch 

John Doe 

0 

Ford 

101010 

10/20/2001 

Auth Ext. 

Left 

2 

0102 



Escort 




Message 



Inrf- 

D4||Egleston 

m 

CP 

Honda 
Civic 

393939 

1 1/02/2001 

Init Auth 

No 

Answer 

0 

0101 

JaUesFarwig 

0 

VWJetta 

2 

09/02/2001 

Auth Ext. 


10 

0103 

Mil Loft 

0 

BMW 

20929 

10/31/2001 

Auth Ext. 


2 

0124 



320i 







Ripiard Smith 

R 

Honda 
Prelude 

la021 

11/01/2001 

Init Auth 

Will 
Call 
Back 

1 

0115 
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A7. Standard Contract List - All Contacts Selected 


Callback Contract List 


Callback Type: Bill-To Group/Branch: 0101-Ladue 

Callback Method: Manual Date/Time: 1 1/2/200 1 1 1 :52A 

Account: STF01 01 -State Farm Contact: Mary Adams 

Phone: 314-555-9090 


Name 

Stat. 

Vehicle 

Claim/Pol 
/PO/RO 

Date of 
Loss 

Primary 
Reason 

Today's 
Action 

Day 
s 

Out. 

Group 
/Branch 

John Doe 

3 ! 

O 

Ford 
Escort 

101010 

10/20/200 
1 

Auth Ext. 

Left 

Message 

2 

0102 

Dap|Egleston 

O 

Honda 
Civic 

393939 

11/02/200 
1 

Init Auth 

No 

Answer 

0 

0101 

Jaips Farwig 

0 

VW 
Jetta 

2 

09/02/200 
1 

Auth Ext. 


10 

0103 

Julie Loft 

is, 1 
"i 

CP 

BMW 
320i 

20929 

10/31/200 
1 

Auth Ext. 

* 

2 

0124 

Ripard Smith 

hi 

R 

Honda 
Prelude 

la021 

11/01/200 
1 

Init Auth 

Will 
Call 
Back 

1 

0115 

1 . ——————————— 

III. 

Page Break — 

>,<*■} , 


Callback Contract List 


Callback Type: Bill-To Group/Branch: 0101-Ladue 

Callback Method: Manual Date/Time: 11/2/2001 11:52A 

Account: STF0 101 -State Farm Contact: Mike Brady 

Phone: 314-555-0009 


Name 

Stat. 

Vehicle 

Claim/Pol 
/PO/RO 

Date of 
Loss 

Primary 
Reason 

Today's 
Action 

Day 
s 

Out 

Group 
/Branch 

John Doe 

O 

Ford 
Escort 

101010 

10/20/200 
1 

Auth Ext. 

Left 

Message 

2 

0102 

Dan Egleston 

O 

Honda 
Civic 

393939 

11/02/200 
1 

Init Auth 

No 

Answer 

0 

0101 

James Farwig 

O 

VW 

2 

09/02/200 

Auth Ext. 


10 

0103 


Jetta 


1 





Julie Loft 

CP 

BMW 
320i 

20929 

10/31/200 
1 

Auth Ext. 


2 

0124 
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Richard Smith R 

Honda la021 

11/01/200 InitAuth Will 

1 

0115 


Prelude 

1 Call 





Back 




Rest of Contacts to Follow. 


F) 


•ni 
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A8. RMS Shop Contract List - All Contacts Selected 


Callback Contract List 


Callback Type: 
Callback Method: 
RMS Account: 
Account: 


RMS - Shop 
Manual 

STF0101 - State Farm 
BAB0101 - Bob's Auto Body 


Group/Branch: 
Date/Time: 
Contact: 
Phone: 


0101-Ladue 
11/2/2001 11:52A 
Mary Adams 
314-555-9090 


Claim/P 


Day 


Name 

Stat. 

Vehicle 

ol 

/PO/RO 

Date of 
Loss 

Primary 
Reason 

Today's 
Action 

s 

Out. 

Group 
/Branch 

John Doe 

O 

Ford 

101010 

10/20/2001 

Auth Ext. 

Left 

2 

0102 

2 i 


Escort 




Message 



DapjEgleston 

CP 

Honda 

393939 

11/02/2001 

Init Auth 

No 

0 

0101 



Civic 




Answer 



Jafflbs Farwig 

o 

VW Jetta 

2 

09/02/2001 

Auth Ext. 


10 

0103 

Julie Loft 

0 

BMW 
320i 

20929 

10/31/2001 

Auth Ext. 


2 

0124 

Riplard Smith 

IPS 5 ' 

R 

Honda 
Prelude 

la021 

11/01/2001 

Init Auth 

Will 
Call 

1 

0115 


Back 


ill 
III 

-1ST 


-- Page Break- 


Callback Type: 
Callback Method: 
RMS Account: 
Account: 


Callback Contract List 

RMS - Shop Group/Branch: 

Manual Date/Time: 

STF0101 - State Farm Contact: 

BAB0101 - Bob's Auto Body Phone: 


0101-Ladue 
11/2/2001 11:52A 
Mike Brady 
314-555-0009 


Claim/P 


Day 


Name 

Stat. 

Vehicle 

ol 

/PO/RO 

Date of 
Loss 

Primary 
Reason 

Today's 
Action 

s 

Out. 

Group 
/Branch 

John Doe 

0 

Ford 
Escort 

101010 

10/20/2001 

Auth Ext. 

Left 

Message 

2 

0102 

Dan Egleston 

CP 

Honda 
Civic 

393939 

1 1/02/2001 

Init Auth 

No 

Answer 

0 

0101 

James Farwig 

o 

VW Jetta 

2 

09/02/2001 

Auth Ext. 


10 

0103 

Julie Loft 

0 

BMW 
320i 

20929 

10/31/2001 

Auth Ext. 


2 

0124 

Richard Smith 

R 

Honda 
Prelude 

la021 

11/01/2001 

Init Auth 

Will 
Call 

1 

0115 
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Version: 1.2 

ECARS 2.0 

Date: 12/21/01 

Callback Summary Print 


Back 


Rest of Contacts to Follow. 


h'f 
III 

W: 

Is I 
'I J 

ST,* 7 
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Version: 1.2 

ECARS 2.0 

Date: 12/21/01 

Callback Summary Print 


A9. Renter List 


Callback Renter List 


Callback Method: Renter Group/Branch: 0101-Ladue 

Callback Type: Manual Date/Time: 1 1/2/200 1 1 1 :52A 

Current Home Day 


Name 

Stat. 

Amount 
Due 

Paymen 
tType 

Phone 
Number 

Primary 
Reason 

Today's 
Action 

s 

Out. 

Contract 
Number 

James Doe 

0 

$100.00 

Cash 

314-555- 
5345 

Balance 
Due 

Left 

Message 

10 

Ad34jk 

Ape Edwards 

CP 

$0.00 

Credit 

314-555- 

Max. Auth 

No 

1 

2A299 

Ci 



Card 

1103 


Answer 



Gebrge Dire 

ill 

3 *, T 

R 

$0.00 

Cash 

314-555- 
6542 

Ticket 
Rewrite 


1 

11399A 


Ci. 
si 


K , S 

ti 

m 
in 
® 

p; 


Confidential 


©Enterprise Rent-A-Car, 
2000 


12 


IB 

Enter 

prise 


rent-a-car 


Project: 

Callback 


Phase; 

Elaboration 



Callback 

Callback Supplementary Specification 

Version <1.0> 


i Wi £ 
III 

ft! 
VI 


Si 


5 » 
HIT S* 


I 



Supplementary Specification 


lof25 
Path: 


Y:\GROUPS\E-Commerce Group\Patent Materials 8_3 lJl\Copy of Ail Patmts\ECARS20 - Callbacks\Supp!emental Specs\Cailback 

Supplementary Spec.doc 


Ill 


Eg 

Enter 

prise 


rent-a-car 


Project: 

Callback 


Phase: 

Elaboration 



Iteration: 

N/A 


Revision History 


Date 

Version 

Description 

Author 

15-May-01 

1.0 

Creation 

PinKoh 

ll-Jun-01 

LI 

Changed scenario description of all rules 

PinKoh 

14-Jun-01 

1.11 

Changed English 

David Flynn 

07-Aug-01 

1.12 

Changed wording on the Renter scenarios 

Leanne Bevelhimer 

13-Aug-01 

1.13 

Re-worded scenarios 

Leanne Bevelhimer 

14-Aug-01 

1.2 

Updated based on meeting with Mary and 
Jon 

Leanne Bevelhimer 


Sl*l SS. 

Hi 

01 

lirl. 



Artifact; 

Supplementary Specification 

Y:\GROUPS\E-Commerce Group\Patent Materials 8JI JACo^ofAii Patents\ECARS20 - CailbacksVSuppiernental Specs\Callback 

Supplementary Spec.doc 


S3 

Enter 

prise 


rent-a-car 1 



Project: 

Callback 


Phase: 

Elaboration 


Iteration: 

N/A 


Table of Contents 


1. Introduction 5 

1.1 Purpose 5 

1.2 Scope 5 
1.2.1.1 Definitions, Acronyms and Abbreviations 5 

1 .3 References 5 

1.4 Overview 5 

2. Functionality 6 

2.1 Callback Date 6 

2.2 Obtain Repair Status 6 

2.2.1 General Rule 6 

]*! 2.2.1.1 Callback Date for Obtain Repair Status 7 

3{ 2.2.2 Obtain Repair Status (RMS) Rule 8 

St 2.2.2.1 Callback Date for Obtain Repair Status (RMS) Rule 8 

$ 2.2.3 Obtain Repair Status (ARMS) Rule 9 

*J 2.2.3.1 Callback Date for Obtain Repair Status (ARMS) Rule 9 

j*; 2.2.4 Completion Criteria $ 9 

'*!■ 2.2 A 1 General Rule 9 

m 2.2.4.2 ARMS 9 

f 2.2.4.3 RMS ; 10 

r k 2.3 Obtain Initial Authorization 11 

Rl 2.3.1 General Rule 11 

111 2.3.1.1 Callback Date for Obtain Initial Authorization 12 

2.3.2 Obtain Initial Authorization (RMS) Rule 12 
2.3.2.1 Callback Date for Obtain Initial Authorization (RMS) Rule 12 

2.3.3 Completion Criteria 13 

2.3.3.1 General Rule 13 

2.33.2 RMS 13 

2.4 Obtain Authorization Extension i4 

2.4.1 General Rule 14 
2.4. 1 . 1 Callback Date for Obtain Authorization Extension 15 

2.4.2 Obtain Initial Authorization (RMS) Rule 15 
2.4.2.1 Callback Date for Obtain Authorization Extension(RMS) Rule 1 5 

2.4.3 Completion Criteria I 6 

2.4.3.1 General Rule 16 

2.4.3.2 RMS 16 

2 .5 Last Day Notification * 7 

2.5.1 General Rule 17 

2.5.2 Callback Date 17 

2.5.3 Completion Criteria 17 
2.6 Balance Due 18 

2.6.1 General Rule 18 

2.6.2 Callback Date 19 

2.6.3 Completion Criteria 19 

rTfifaT? Page: Last save(i: 

IStaentaiy Specification 3tf25 12/20/01 12:37 PM 

Path: 

Y:\GROUPS\E-Commerce GroupXPatent Materials 8_31_01\Copy of All PatentslECARS20 - CaIibacks\Supplemental SpecsVCaliback 

Supplementary Spec.doc 


IS 

Enter 

prise 


rent-a-car 


Project; 

Callback 



Phase: 

Elaboration 


Iteration: 

N/A 


3. 
4. 
5. 

6. 
7. 
8. 
9. 
10. 


11. 
12. 
13. 


2.7 Past Estimated Return Date 19 

2.7.1 General Rule 19 

2.7.2 Callback Date 20 

2.7.3 Completion Criteria 20 

2.8 Ticket Rewrite 21 

2.8.1 General Rule 21 

2.8.2 Callback Date 21 

2.8.3 Completion Criteria 21 

2.9 Maximum Authorized Amount Reached 2 1 

2.9.1 General Rule 21 

2.9.2 Callback Date 22 

2.9.3 Completion Criteria 22 

2.10 Miscellaneous 22 

Usability 22 

Reliability 23 

Performance 23 

5.1 Callback Generation * 23 

Supportability 23 

Design Constraints 23 

Online The user Documentation and Help System Requirements 2 3 

Purchased Components 23 

Interfaces 23 

10.1 Hardware Interfaces 23 

10.2 Software Interfaces 23 

1 0.3 Communications Interfaces 23 

Licensing Requirements 24 

Legal, Copyright and Other Notices 24 

Applicable Standards • 24 


Artifact: 
Supplementary Specification 


4 of 25 
Path: 


Last saved: 

12/20/01 12:37 PM 


Y:\GROUPS\E-Commerce Group\Patent Materials 8J1 _01\Copy of All Patents\ECARS20 - Ca!Ibacks\Supplemental Specs\Callback 

Supplementary Spec.doc 


IS 

Enter 

prise 

lii 

rent-a-car 



Project: 

Callback 


Phase: 

Elaboration 


Iteration: 

N/A 


Callback Supplementary Specification 

1. Introduction 

The Supplementary Specification captures the system requirements that are not readily 
captured in the all use cases of the use-case model for callback 

1.1 Purpose 

The purpose of this document is to detail callback generation and completion for all rules. 

1.2 Scope 

This document supports all the use cases pertaining to the Callback project. 

1 .2.1 .1 Definitions, Acronyms and Abbreviations 

Refer to the Glossary document for details. 

1.3 References 

Generate Callback Use Case 

1.4 Overview # 

The main content of this document attempts to document in detail the business rule that governs the life- 
cycle of all callbacks. It describes the conditions, actions and results that affects callbacks. 
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Figure 1: Shop and Bill To Callback Summary. 
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Figure 2: Renter Callback Summary screen. 
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Figure 3: Message Status Dialog - Displayed when the Update Message Button is pressed 
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2.1 NavigationBar 

2.1,1 Manual Total 

2.1.1.1 Behavior 

This output only field will display the total number of Manual Callbacks for selected Group 
Branch. 

2.1.1.2 Validation 

None specified at this time. 

2.1.1.3 Business Exceptions 
None specified at this time. 

2.1.1.4 System Exceptions 
None specified at this time. 

2.12 ManualShopTotal 

2.1.2.1 Behavior 

This button will display the total number of Manual Shop Callbacks for the selected Group 
Branch. When this button is pressed, the Content Panels Account Table is refreshed to show data 
for Manual Shop callbacks for the selected Group Branch, and the renter and Contact Tables are 
cleared. Both the Perform Callbacks and Update Message Status buttons are visible, but disabled. 

2.1.2.2 Validation 

None specified at this time. 

2.1.2.3 Business Exceptions 
None specified at this time. 

2.1.2.4 System Exceptions 
None specified at this time. 
2.1.3 ManualBHIToTotal 

2.1.3.1 Behavior 

This button will display the total number of Manual Bill-To Callbacks for the selected Group 
Branch. When this button is pressed, the Content Panels Account Table is refreshed to show data 
for Manual Bill-To callbacks for the selected Group Branch, and the renter and Contact Tables 
are cleared. Both the Perform Callbacks and Update Message status buttons are visible, but 
disabled. 

2.1.3.2 Validation 
None specified at this time. 

2.1.3.3 Business Exceptions 
None specified at this time. 
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2.1.3.4 System Exceptions 
None specified at this time. 

2.1.4 ManualRenterTotal 
2.14.1 Behavior 

This button will display the total number of Manual Renter Callbacks for the selected Group 
Branch. When this button is pressed, the Content Panel's Renter Table is refreshed to show data 
for Manual Renter callbacks for the selected Group Branch. Only the Renter Table is visible and 
only the Perform Callbacks button is visible, but disabled. 

2.1.4.2 Validation 
None specified at this time. 

2.1.4.3 Business Exceptions 
J I None specified at this time. 

2. 1 .4.4 System Exceptions 
None specified at this time. 

2.1.5 Automated Total * 
This output only field will display the total number of Automated Callbacks for the selected 
Group Branch. 

2.1.5.1 Behavior 

2.1.5.2 Validation 
None specified at this time. 

2.1.5.3 Business Exceptions 
None specified at this time. 

2.1.5.4 System Exceptions 
None specified at this time. 

2.16 AutomatedShopTotal 

2.1.6.1 Behavior 

This button will display the total number of Automated Shop Callbacks for the selected Group 
Branch. When this button is pressed, the Content Panel's Account Table is refreshed to show 
data for Automated Shop callbacks for the selected Group Branch, and the Renter and Contact 
Tables are cleared. Neither the Perform Callbacks nor the Update Message Status buttons are 
enabled. 

2.1.6.2 Validation 
None specified at this time. 

2.1.6.3 Business Exceptions 
None specified at this time. 
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2.1.6.4 System Exceptions 
None specified at this time. 

2.1.7 AutomatedBillToTotal 
2.17.1 Behavior 

This button will display the total number of Automated Bill-To Callbacks for the selected Group 
Branch, When this button is pressed, the Content Panel's Account Table is refreshed to show 
data for Automated Bill-To callbacks for the selected Group Branch, and the Renter and Contact 
Tables are cleared. Neither the Perform Callbacks nor the Update Message Status buttons are 
enabled. 

2.1.7.2 Validation 

None specified at this time. 

2.1.7.3 Business Exceptions 
None specified at this time. 

2.17.4 System Exceptions 

None specified at this time. * 

2.1.8 FaxTotal 

2.18.1 Behavior 

This output only field will display the total number of Fax Callbacks for the selected Group 
Branch. 

2.18.2 Validation 

None specified at this time. 

2.18.3 Business Exceptions 
None specified at this time. 

2.1 .8.4 System Exceptions 
None specified at this time. 

2.19 FaxShopTotal 

2.19.1 Behavior 

This button will display the total number of Fax Shop Callbacks for the selected Group Branch. 
When this button is pressed, the Content Panel's Account Table is refreshed to show data for Fax 
Shop callbacks for the selected Group Branch, and the Renter and Contact Tables are cleared. 
Neither the Perform Callbacks nor the Update Message Status buttons are enabled. 

2.19.2 Validation 

None specified at this time. 

2.19.3 Business Exceptions 
None specified at this time. 
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2.1.9.4 System Exceptions 
None specified at this time. 

2.1.10 FaxBHIToTotal 

2.1.10.1 Behavior 

This button will display the total number of Automated Shop Callbacks for the selected Group 
Branch. When this button is pressed, the Content Panel's Account Table is refreshed to show 
data for Automated Shop callbacks for the selected Group Branch, and the Renter and Contact 
Tables are cleared. Neither the Perform Callbacks nor the Update Message Status buttons are 
enabled. 

2.1.10.2 Validation 

None specified at this time. 

2.1.1 0.3 Business Exceptions 
None specified at this time. 

2.1.10.4 System Exceptions 

None specified at this time. * 

2.1.11 ConsolodatedTotal 

2.1.11.1 Behavior 

This output only field will display the total number of Consolidated Callbacks for the selected 
Group Branch. 

2.1.11.2 Validation 

None specified at this time. 

2.1 .1 1 .3 Business Exceptions 
None specified at this time. 

2.1.1 1 .4 System Exceptions 
None specified at this time. 

2.1.12 ConsolodatedShopTotal 

2.1.12.1 Behavior 

This button will display the total number of Consolidated Shop Callbacks for the selected Group 
Branch. When this button is pressed, the Content Panel's Account Table is refreshed to show 
data for Consolidated Shop callbacks for the selected Group Branch, and the Renter and Contact 
Tables are cleared. Neither the Perform Callbacks nor the Update Message Status buttons are 
enabled. 

2.1.12.2 Validation 
None specified at this time. 
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2.1.12.3 Business Exceptions 
None specified at this time. 

2.1.12.4 System Exceptions 
None specified at this time. 

2.1.13 ConsolodatedBiilToTotal 
2.1.13.1 Behavior 

This button will display the total number of Consolidated Bill-To Callbacks for the selected 
Group Branch. When this button is pressed, the Content Panel's Account Table is refreshed to 
show data for Consolidated Bill-To callbacks for the selected Group Branch, and the Renter and 
Contact Tables are cleared. Neither the Perform Callbacks nor the Update Message Status 
buttons are enabled. 

2.113.2 Validation 

None specified at this time. 

2.1.13.3 Business Exceptions 

None specified at this time. * 

2.1.13.4 System Exceptions 
None specified at this time. 

2.1.14 RMS Total 

2.1.14.1 Behavior 

This output only field will display the total number of RMS Callbacks for selected Group 
Branch. 

2.1.14.2 Validation 

This field is only displayed for an RMS employee. 

2.1.14.3 Business Exceptions 
None specified at this time. 

2.1.14.4 System Exceptions 
None specified at this time. 

2.1.15 RMSShopToial 
2.1.15.1 Behavior 

This button will display the total number of RMS Shop Callbacks for the selected Group Branch. 
When this button is pressed, the Content Panels Account Table is refreshed to show data for 
RMS Shop callbacks for the selected Group Branch, and the renter and Contact Tables are 
cleared. Both the Perform Callbacks and Update Message Status buttons are visible, but disabled. 
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2.1.15.2 Validation 

This field is only displayed for an RMS employee. 

2. 1 . 1 5.3 Business Exceptions 
None specified at this time* 

2.1.15.4 System Exceptions 
None specified at this time. 

11.16 RmBiIIToTqtal 

2.1.16.1 Behavior 

This button will display the total number of RMS Bill-To Callbacks for the selected Group 
Branch. When this button is pressed, the Content Panels Account Table is refreshed to show data 
p! for RMS Bill-To callbacks for the selected Group Branch, and the renter and Contact Tables are 
p cleared. Both the Perform Callbacks and Update Message status buttons are visible, but disabled. 

|| 2.1.16.2 Validation 

E- This field is only displayed for an RMS employee. 

■*I 2.1.16.3 Business Exceptions 
None specified at this time. 

2.1.16.4 System Exceptions 
None specified at this time. 

2.1.17 RMSReoierTdtal 

2.1.17.1 Behavior 

This button will display the total number of RMS Renter Callbacks for the selected Group 
Branch. When this button is pressed, the Content Panel's Renter Table is refreshed to show data 
for RMS Renter callbacks for the selected Group Branch. Only the Renter Table is visible and 
only the Perform Callbacks button is visible, but disabled. 

2.1.17.2 Validation 

This field is only displayed for an RMS employee. 

2.1.17.3 Business Exceptions 
None specified at this time. 

2.1.17.4 System Exceptions 
None specified at this time. 

2.178 Account Table 

This table contains all accounts contained in all callbacks for the selected Group Branch and 
Callback Type. When an account is selected, the contacts table is loaded with all the contacts for 
that account that has a callback for that Group Branch and Callback Type. The Perform 
Callbacks Button is disabled. 
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2.118.1 Name 

2.1.18.1.1 Behavior 

This output only field contains the name of the account. 

2.1.18.1.2 Validation 

None specified at this time. 

2. 1 . 1 8 . 1 .3 Business Exceptions 

None specified at this time. 

2. 1 . 1 8. 1 .4 System Exceptions 

None specified at this time. 

2.1.18.2 Telephone Number 

2.1.18.2.1 Behavior 

This output only field contains the telephone number of the account. t 

2.1.18.2.2 Validation 

None specified at this time. 

2.1.18 .2.3 Business Exceptions 

None specified at this time. 

2.1.18.2.4 System Exceptions 

None specified at this time. 

2.1.18.3 Number Of Calls 

2.1.18.3.1 Behavior 

This output only field contains the number of calls that particular account has for the selected 
Group, Branch, and Callback Type. 

2.1.18.3.2 Validation 

None specified at this time. 

2.1.18.3.3 Business Exceptions 

None specified at this time. 

2.1.18.3.4 System Exceptions 

None specified at this time. 
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2.1.18.4 Left Messages 

2.1.1 8.4.1 Behavior 

This output only field contains the number of messages left for that particular account for the 
selected Group, Branch, and Callback Type. 

2.1.18.4.2 Validation 

None specified at this time. 

2.1.1 8.4.3 Business Exceptions 

None specified at this time. 

2.1.1 8.4.4 System Exceptions 

None specified at this time. 

2.1.18.5 Account No. 

2.1.18.5.1 Behavior 

This output only field contains the account number for the Account. 

2.1.18.5.2 Validation 

None specified at this time. 

2. 1 . 1 8.5 .3 Business Exceptions 

None specified at this time. 

2. 1 . 1 8.5.4 System Exceptions 

None specified at this time. 

2.1.18.6 Address 

2.1.18.6.1 Behavior 
This output only field contains the account's address. 

2.1.18.6.2 Validation 

None specified at this time. 

2. 1 .1 8.6.3 Business Exceptions 

None specified at this time. 

2.1.1 8.6.4 System Exceptions 

None specified at this time. 
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2.1.19 Contact Table 

This table contains all contacts for the selected account contained in all callbacks for the selected 
Group Branch and Callback Type. When a contact is selected, the renter table is loaded with all 
the renter and contracts for that account and contact that has a callback for that Group Branch 
and Callback Type. The Perform Callbacks Button is disabled, 

2.1.19.1 Name 

2.1.19.1.1 Behavior 

The name of the contact. 

2.1.19.1.2 Validation 

None specified at this time. 

2.1.19.1.3 Business Exceptions 

None specified at this time. 

2.1.19.1.4 System Exceptions t 

None specified at this time. 

2.1.1 9.2 Telephone Number 

2.1.19.2.1 Behavior 
The telephone number of the contact. 

2.1.19.2.2 Validation 

None specified at this time. 

2.1.1 9.2.3 Business Exceptions 

None specified at this time. 

2.1.19.2.4 System Exceptions 

None specified at this time. 

2.1.19.3 Number Of Calls 

2.L19.3.1 Behavior 

The number of calls for that Contact for the selected Group Branch and Callback Type. 

2.1.19.3.2 Validation 

None specified at this time. 

2. 1 . 1 9.3 .3 Business Exceptions 
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None specified at this time. 

2.1.1 9.3 .4 System Exceptions 

None specified at this time. 
2.1.19.4 Left Messages 

2.1.19.4.1 Behavior 

The number of messages left for that contact for the selected Group Branch and Callback Type 

2.L19.4.2 Validation 

None specified at this time. 


□ 2.1.19.4.3 Business Exceptions 

None specified at this time. 


m 

Pi 2.1.19.4.4 System Exceptions 

hi 

SI 


None specified at this time. * 
2.1.20 Renter Table 

This table contains information about Renters, Contracts, and Callbacks for the selected Group, 
Branch, Account, Callback Type and Contact. Multiple Renters' can be selected. When one or 
[if more rows in the Renter table are selected, the Perform Callbacks button becomes enabled to 
~t perform a callback except for Automated, Fax, and Consolidated Callback Methods. 

2.120.1 Name 


2.1.20.1.1 Behavior 

The name of the renter 

2.1.20.1.2 Validation 

None specified at this time. 

2. 1 .20. 1 .3 Business Exceptions 

None specified at this time. 

2. 1 .20. 1 .4 System Exceptions 

None specified at this time. 
2.1.20.2 Vehicle 

2.1.20.2.1 Behavior 

The Year Make Model and Color of the Vehicle Rented? Or the Renter's Vehicle in the Shop? 
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2.1.20.2.2 Validation 

None specified at this time. 

2. 1 .20.2.3 Business Exceptions 

None specified at this time. 

2.1.20.2.4 System Exceptions 

None specified at this time. 
2.1.20.3 Ciaim/Pol/PO/RO 

2.1.20.3.1 Behavior 

The Claim Number, Policy Number, Purchase Order Number, or Repair Order Number. 

2.1.20.3.2 Validation 

None specified at this time. 

2.1.20.33 Business Exceptions # 

None specified at this time. 

2.1 .20.3 .4 System Exceptions 

None specified at this time. 
2.120.4 Date of Loss 

2.1.20.4.1 Behavior 
The date the renter's vehicle was damaged. 

2.1.20.4.2 Validation 

None specified at this time. 

2. 1 .20.4.3 Business Exceptions 

None specified at this time. 

2.1.20.4.4 System Exceptions 

None specified at this time. 
2.1.20.5 Primary Reason 

2.1.20.5.1 Behavior 

The reason for the callback. 

2.1.20.5.2 Validation 
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None specified at this time. 

None specified at this time. 

None specified at this time. 
2.1.20.6 Today's Action 


2. 1 .20.5.3 Business Exceptions 


2. 1 .20.5 .4 System Exceptions 


2.1.20.6.1 Behavior 
The action required for this callback. 


C 

r 
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m 
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I None specified at this time. 


2.1.20.6.2 Validation 


2.1.20.6.3 Business Exceptions 


2. 1 .20.6.4 System Exceptions 


None specified at this time. 

None specified at this time. 

2.1.20.7 Days Outstanding 

2.1.20.7.1 Behavior 

The number of days since the date for which the callback was generated. 

2.1.20.7.2 Validation 

None specified at this time. 
None specified at this time. 

None specified at this time. 

2.1.20.8 Contract Number 

2.1.20.8.1 Behavior 
The contract number for the callback. 


2. 1 .20.7.3 Business Exceptions 


2.1.20.7.4 System Exceptions 


2.1.20.8.2 Validation 


None specified at this time. 
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2. 1 .20.83 Business Exceptions 

None specified at this time. 

2. 1 .20.8.4 System Exceptions 

None specified at this time. 
2.2 Renter Content Panel 

2. 2. 1 Group & Branch 

See Group and Branch in the Bill-To and Shop Content Panel. 

2.2.2 Renter Table 

This table contains information about Renters, Contracts, and Callbacks for the selected Group, 
Branch, Account, Callback Type and Contact. Multiple Renters' can be selected. When one or 
more rows in the Renter table are selected, the Perform Callbacks button becomes enabled to 
perform a callback except for Automated, Fax, and Consolidated Callback Methods. 

2.2.2.1 Name 

The Renter's name. 

222 A A Behavior 

2.2.2.1.2 Validation 

None specified at this time. 

2.2.2.1.3 Business Exceptions 

None specified at this time. 

222.1 A System Exceptions . 

None specified at this time. 

2.2.2.2 Current Amount Due 

2.2.2.2.1 Behavior 
The amount owed by the renter. 

2.2.2.2.2 Validation 

None specified at this time. 

2.2.2.2.3 Business Exceptions 

None specified at this time. 

2.2.2.2.4 System Exceptions 

None specified at this time. 
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2.2.2.3 Payment Type 

2.2.2.3.1 Behavior 

The type of payment the renter used when picking up the vehicle. 

2.2.2.3.2 Validation 

None specified at this time. 
None specified at this time. 

None specified at this time. 

2.2.2.4 Home Phone Number 

2.2.2.4.1 Behavior 
The home phone number for the renter 


2.2.2.3.3 Business Exceptions 


2.2.2.3.4 System Exceptions 


None specified at this time. 


f|| None specified at this time. 


H 


2.2.2.4.2 Validation 


2.2.2.4.3 Business Exceptions 


2.2.2.4.4 System Exceptions 


None specified at this time. 
2.2.2.5 Primary Reason 

The reason for the callback. 

None specified at this time. 

None specified at this time. 

None specified at this time. 


2.2.2.5.1 Behavior 


2.2.2.5.2 Validation 


2.2.2.5.3 Business Exceptions 


2.2.2.5.4 System Exceptions 
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2.2.2*6.3 Business Exceptions 


2.2.2.6.4 System Exceptions 


2.2.2.6 Today's Action 

2.2.2.6.1 Behavior 
The action required for today's callback. 

2.2.2.6.2 Validation 

None specified at this time. 
None specified at this time. 

None specified at this time. 

2.2.2.7 Days Outstanding 

2.2.2.7.1 Behavior 

The number of days since the date for which the callback was generated. 

2.2.2.7.2 Validation 

None specified at this time. 
None specified at this time. 

None specified at this time. 

2.2.2.8 Contract Number 

2.2.2.8.1 Behavior 
The contract number the callback is for. 


2.2,2.7,3 Business Exceptions 


2.2.2.7.4 System Exceptions 


None specified at this time. 


None specified at this time. 


None specified at this time. 


2.2.2.8.2 Validation 


2.2.2.8.3 Business Exceptions 


2.2.2.8.4 System, Exceptions 
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2.3 Message Status Dialog 

This dialog is displayed when the Update Message Status button is pressed. 

2.3.1 Left Message 

2.3.1.1 Behavior 

This button could be selected if a message was left regarding the selected callback. 

2.3.1.2 Validation 
None specified at this time. 

2.3.1.3 Business Exceptions 
None specified at this time. 

2.3.1.4 System Exceptions 
None specified at this time. 

2.3.2 No Answer 

2.3.2.1 Behavior 

This button could be selected if an attempt was made for a callback but therp was no answer. 

2.3.2.2 Validation 

None specified at this time. 

*t . 2.3.2.3 Business Exceptions 
1| None specified at this time. 

p 2.3.2.4 System Exceptions 
4 None specified at this time. 

2.3.3 Contact will call back 

2.3.3.1 Behavior 

This button could be selected if someone was contacted and indicated that they will callback at a 
later time. 

2.3.3.2 Validation 

None specified at this time, 

2.3.3.3 Business Exceptions 
None specified at this time. 

2.3.3.4 System Exceptions 
None specified at this time. 

2.3.4 Person Contacted 
2.3.4.1 Behavior 

The person who was contacted when a message was left. 
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2.3.4.2 Validation 

None specified at this time. 

2.3.4.3 Business Exceptions 
None specified at this time. 

2.3.4.4 System Exceptions 
None specified at this time. 

2.4 Rules 

1 . A user must be able to select any Branch within their Group for which to view Callbacks for the selected 
Branch. 

2. Upon initial entry to Callback Summary the default Group and Branch will be for the requesting terminal's 
Group and Branch and the "Manual" Callback Method and "Shop" Callback Type will be selected on the 
Navigation Bar. 

3. Callbacks must be grouped into Callback Methods to indicate how the user should perform the callback. 

4. Callbacks must be grouped into Callback Types to indicate to whom the callback should be performed. 

5. Applicable Callback Types should be listed under the Callback Methods that can be used to perform a callback 
of this type. 

6. Shop Callbacks can be performed by the following Callback Methods: $ 

• Manual 

• Automated 

• Fax 

• Consolidated 

7. Bill To Callbacks can be performed by the following Callback Methods: 

• Manual 

• Automated 

• Fax 

• Consolidated 

8. Renter Callbacks can be performed by the following Callback Methods: 

• Manual 

9. The user must be able to select a single Callback Type for a Callback Method and view all contracts associated 
with that selected Callback Type and method. 

10. The total number of callbacks needing to be performed by a Callback Method, for a particular group/branch, 
should be displayed for each Callback Method. 

1 1 . The total number of callbacks needing to be performed to a particular Callback Type, for a particular 
group/branch, should be calculated and displayed for each Callback Type for each Callback Method. 

12. The number of calls should only calculate the, callbacks that are in an "incomplete" status for the particular 
Callback Method or the Callback Type under a Callback Method, for a particular group/branch. 

13. The number of calls column should be re-calculated every time the user selects to refresh the data on the screen 
or leaves die window and returns back to the window so they can see their updates to the callbacks immediately. 

14. ^eafsfiSDidd ^esemr gb-bapk tp;cor^rate wh^iefreisl&^y^ time aiefresh isrequested or only when a 
Message has teen sefit from corporate that some event has occurred that affects the ^Hmck Bimmiary list? 

15. When the requesting terminal is from a Callback Center Group and Branch; those Callbacks that are 
consolidated to this Group and Branch should be grouped to the appropriate Callback Type under the "Manual" 
Callback Method. 

16. When the requesting tenninal is from a Renting Group and Branch; those Callbacks where the requesting Group 
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and Branch is the owning Group/Branch for the Contract that has a Callback record, that are consolidated to 
another Group and Branch should be grouped to the appropriate Callback Type under the "Consolidated" 
Callback Method. 


2.5 Security 

1 . For security checks we will use the architecture security framework to determine if a user can access a 
reservation/contract based on their access levels. 

2. We will need an application security check (separate from the security framework) for certain branches to 
determine if they can edit certain contracts, that are for a country other than theirs, for which they are 
responsible for performing the callbacks, (i.e. Canada branches may be responsible for Cars that are rented from 
a Florida branch but the Canada branch is required to do the callbacks for the Bill To account). The branch will 
need the ability to edit the contract regardless of how they select the contract. A solution may be to have a 
generic Kiosk Id, where the id allows editing of contracts across countries. 

2.6 Questions 

3. What happens when the user clicks on the Fax, Automated, or Consolidated buttons? Should we show the same 
content panel, or is there different information displayed for the other methods of callbacks. 

4. Does the Update Message Status button belong to an entire account, a contact, or a particular callback? If it 
belongs to a particular callback (or set of selected callbacks) the Update Message States button should be 
underneath the Renter Table. If it belongs to a particular contact, the Update Message Status button should be 
under the Contact table. 

5 . What is the formula for Days Outstanding? 

6. What is the Vehicle in the Renter's table? Is it the Renter's Vehicle in the Shop? Is it the Rented Vehicle? 
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1. Expandable Table 
1.1 Screen Shots 
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Figure 4: Callback Summary with the table's normal size. 
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Figure 5: Callback Summary with the account table expanded. 
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Figure 6: Callback Summary with the contact table expanded. 
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Figure 7: Callback Summary with the renter table expanded. 


1.2 Behavior 


1.2.1 Overview 

The expandable table is used to give the user the option to see a longer list of data to select from 
or view. This is similar to the way a combo box works. When the user clicks the + button, the 
table expands as large as it can without loosing the vertical scroll bar. The table remains 
expanded until the user clicks the - button, or an item is selected. The expandable table should 
expand down if space is sufficient, however, it may expand up if there is no room below the table 
as in Figure 7. 
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4. Moved validation of date to after 
the "Save" step. (In HTML, Date 
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Use Case Specification: Enter Renter's/Additional 
Driver's Insurance Information 


1. Enter Renter's/Additional Driver's insurance Information Use Case 

1 .1 Brief Description 

This use case will describe the interaction that occurs between a user and the system when the 
user inputs and selects details pertaining to the insurance information about a person who is a 
renter or additional driver. 

2. Flow of Events 

2.1 Basic Flow 

2. 1. 1 Insurance Detail Area 

The Enter R enter's/Additional Driver's Insurance Information Use Case begins when the 
system disp lays the area for entry a nd selection of insurance information about the person who 
is a renter or additional driver. The fields i n this area are: 

Information a bout the Insurance Company # 

• Carrier 

• Phone Number 

• Name of Insurance Com pany Contact 

• Policy Number 

• Expiration Date 

Information about the renter's or the additional driver's insurance 

• Comprehensive Deductible 
0 Collision Deductible 

• Liability? 
o (Blank) 
o Y§§ 

o Ms 

• Assigned Risk? 
o (Blank) 

o YM 
o Mq 

• Lienholder Policy? 

o ¥§§ 
o _No 


2. 12 Option to Cancel / Exit 

The system displays the option for the user to Cancel/Exit At any point during the entry of 
insurance information the user could decide to cancel out of th e entry process at which time the 
use case would continue at alternate flow Cancel/ Exit. 
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2.1.3 Option to Save 

The system displays the option to Save. At any point during the entry of insurance information 
the user could decide to Save at whi ch time the use case would continue at basic flow Save. 


2. 1. 4 Company and Insurance Detail Information Area Entry 

The user can enter information in the following fields: the name of the Carrier, the name of the 
Agent, Phone Number, Insurance Company Contact, Policy Number, Expiration Date, the 
Collision Deductible amount and the Comprehensive Deductible amount The user can also 
select the available choices for Liability, Assigned Risk, and Lienholder Policy. There are no 
default values for any of the above fields. 


2. 1.5 Select Save Option 

The user selects the option to Save. 


p 2.1.6 Validation of Date 

ill The system validates the value in the Expiration Date field. If the Date value is not valid 

because it does not exist (for example 02/30/02) the use case continues at alternate flow 
Invalid Date . If the Date value is not valid because the Expiration Date is prior to the current 
date the use case continues at alternate flow Expired Policy Date . # 


i !1 


2. 1. 7 Validation of Information Entry 

Jim system validates that if informati on is entered in any one of th e following field?, that all of 
f^l the other fiel ds listed also have information entered in them: 

• Carrier 


* Insurance Company Contact 
® Policy Number 

* Expiration Date 

• Collision Deductible 

♦ Comprehensive Deductible 

• Liability: Yes/No 

If the system determines that anv of the above fie lds are missing information, the system will 
present the user with a feedback message as to what fields are not filled to complete 
Insurance Information. The system will display the option for the user to proceed back to 
Company an d Insuranc e Detail Information Area Entry in the basic flow to complete entnL 

2.1.8 Save 

The system sa ves all the inf ormation entered and sel ected in the fields of the of this use case 
flow . This would be: 



Phone Number 
Insurance C ompany Contact 
Policy Number 
Expiration Date 
Comprehen sive Deductible 
Collision Deductible 
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• Liability?: (Blank*. Yes. No 

• Assianed Risk?: fBlankVYes. No 

• Lienhoider Po!icv?: fBlanklYes. No 


2.1.9 End 


The Use Case ends. 



2.2 Alternative Flows 

2.2.1 Cancel /Exit 

2.2. 1 . 1 The user selects the option to Cancel / Exit. 

2.2.1.2 The system displays a fee dback message warning that the insu rance data will be lost if the 
^ user selects to Cancel / Exit. 

| 2.2.1.3 The system displays t he followi ng options: 

I • Yes: to exit and lose data. 

I • No: return to the use case. 

I (The default option will be No: return to the use case.) 

\ 

J 2.2.1 .4 The user selects Yes the use case ends. If the user selects No, then continue in basic flow at 
the point where the user selected to Cancel / Exit. 

k - 2.2.2 Invalid Date 

J 2.2.2.1 The system displays a feedback message that the Date is invalid. 

I 2.2.2.2 The system prompts the user to correct the Date that is invalid. 

1 2.2.2.3 The user selects to correct the Date and the use case proceeds back to Company and 
* Insurance Detail Information Area Entry in the basic flow. 

2-2.3 Expired Policy Date 

2.2.3.1 The system displays a feedback message that the policy has expired. 

2.2.3.2 The system prompts the user to : 

• Correct the policy exp iration date. 

• Exit the Insurance information Entry process. 

2.2.3.3 If the user selects to change the expiration date the use case proceeds back to Company and 
Insurance Detail Information Area Entry in the basic flow. If the user selects to exit the open 
ticket process the use case continues at alternate flow Cancel / Exit . 

3. Special Requirements 

4. Pre-Conditions 

A user is already authorized through a login process to access the panel that is necessary to: 

• Create or edit a reservation. 
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• Open, edit or close a rental ticket 


6. Post-Conditions 

6. Extension Points 

7. Questions 

Question: In the Employee Approval of the Renter's Insurance Information area should there 

be further security? (for example: update code). Or can the user just input the employee 

number and have the system save it as long as it is a valid employee? 

Answer: No further security is needed. The employee number information will be automatically 

populated into the correct field. This field is display only and the information in it cannot be 

changed. 

Question: What European requirements are there? 

Answer: Jon Jouris has indicated there could be translations for the U.K., Germany etc. Fields 
could be eliminated or labels could changed. 

As of 06/06/2001 an electronic copy of this document had been sent to Jon Jouris so that he 
can pass it on to the appropriate European personnel for feedback. * 
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Use Case Specification: Bill-to 

1. Bill-to 

1 .1 Brief Description 

This use case describes the "Bill-to process" within the context of the ticket or the reservation. The "Bill-to 
process" is limited here to adding and deleting an account number as a Bill-to, and adding, changing, 
extending and deleting an authorization. 

This use case will encompass all of the requirements that are relevant from ECARS 1.0 as well as those 
from VRS which are deemed part of the 1 st phase of ECARS 2.0. This use case only pertains to non- 
ARMS transactions. 
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2. Flow of Events 

2.1 Basic Flow. 

2.1.1 Add a Bill-to 

2.1.11 The user navigates, within the Ticket or the Reservation, to the B ill-to area. 

2.1.12 The system allows the user to indicate w ho will be billed. 

2.1.13 The user can search for a n Bccouni bv name or s/he can enter the account number directly. 

2.1.14 If the user elects to search for the account t he system will first provide a list of the accounts 
alread y in use on the ticket or reservation (if applicable) a nd provide a list of the branch's most 
commonly us ed accounts, as determined bv the criteria in the branch desc ription in TXQ1. If the 
user elects to use an account not in this list, thev can search across all of the accounts on file . 

2.115 If there is no account in the system for the intended bill-to, see alternative flow: Account not on 
file, if the user elects to enter the account number without search T the syste m must vaiiciate the 
account before proceeding . 

2.116 The user se lects a contact . If the contact is not fou nd, the user elects to add one an d enters the 
contacf s full name, phone number and phone number. Either the fir st name or last name is 
reouired. This is saved on the ticket / reservation, as well as being added a s a contact for the 
account 

2.11.7 The user must select an authorization status. 

2.118 System loos the details in t he "Notes". 

2.119 Use Case Ends 

2.2 Alternative Flows 
2.2.1 Remove a Bill-to 

2.2.11 The user navigates, within the Ticket or the Reservation, to the Bill-to area. 
2.2.1.2 The user indicates that s /he wishes to remove a Bill-to. 

2.2.13 The user selects the Bill-to account number whic h s/he wis hes to remove from amon g the bill-tos 
on the tick et or reservation. Any bill-to on the ticket which has at least one ARMS auth orization 
associated to it cannot be removed and therefore shouldn't be presented to the user as an 
option. 

2.2.14 The system displays to the user all of the details of any authorizations a ssociated will the Bill-to 


for that ticket or reservation along with the o ption to can cel their choice. 


2.2.15 User elects to continue. If thev elect to cancel, the use case ends . 

2.2.16 The system removes the bill-to from the ticket or reservation as well as anv authorizations and all 
re quired billing information associated to the b ill-to and loos the details in the "Notes". 

2.2.17 If there are other Bill-tos on the ticket or reservation, and thev are a higher number bill-to. then 
they will be changed to a lower number. (For example, if Bill-to One is Smith Insu rance and Bill- 
to Two is Brown Auto Body, and the user removes Smith insurance from the reservation/ticket, 
then Brown Auto Body becomes Bill-to One.) 

2.2.1.8 The use case ends. 

2.2.2 Add authoriz ation details 

The user na vigates, within the Ticket o r the Reservati onJ:_o flie Bill-to area . 

The user indicates tha t s/he wishes to add an aut horization. 
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The,svstem presents the user with theJMlowing fields: 



Authorization status (Authorized, Pending Authorization, Declined, Terminated, 
Reimbursed, Fending Call at Open) 

Daily amount of authorization 

Itemfs) authorized 

date and time authorized 

ite and time authorized 

• Final date of authorization faJk.a. "Last Dav"^ 

• Person from the bill- to or ganizati on who gave the authorization. 

• Maximum amount of authorization 

• Maximum number of days of authorization 

• "All charges" authorization 

• Informatio n required bv the bill-to f mav be limited bv leg acy to the existing text 
fields for the Clai m /FO/RQ and Insured Name fieldsV 

In order to add an authorization, the user must chang e autho rization status to "Authorized" and enter the 
required information, as deter mined bv the situation. (See add daily authorization add authorization 
maximums, flat authorization, last dav and required information for the details.) t 

The system automatically enters the details of the authorization io tojtfi^ 

the^ ntemrise employee who perfomied the auth orjzMijmas well as all of the associated details. 

The use case ends. 

2.2.2.1 Add daily authorization 

The user indicates that s/he wishes to add a daily authorization. 

User indicates the following: 

The amount per dav that is audiorized. 

The item or items to which that amount is to be applied. 

Whether or not that amount includes tax or is "plus tax" which allows the taxfes^ to be added 
to the authorization. 

The date the authorization is effective. If the bill in g cvcle is 24 hour, then the time is also 
re quired . These should default to the date and time tha t the ticket was opened, or to the 
date and time of the reservation (if available! 

The end date of the authorization or the number of davs of the authorization. If the number 
of davs is indicated, then the system will determine the end date. If a 24 hour billing cvcie, 

The name of the person from the bill-to account who m ade the authorization. 

2.2.2.2 Add authorization maximums 

The user indicates that s/he wishes to add an authorization maximum. 


The maximum amount that the bill-to can be billed, the m aximum number of davs that fliev 
can be billed, or both . If thev indicate both, thev system will apply whichever is the lesser! 
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The name of the person from the bill-to account who set the maximum. 

NOTE: The maximum amount is a flat maximum - there will be no option to indicate an 
amount + tax, etc., 

2.2.2.3 Last Dav 

IJs_ej:jjKli^^^ 

The date beyond which no charges may be applied to the bill-to . 
The name of the person from the bill-to account who set the final date. 

2.2.3 Change Authorization Amount 

2.2.3.1 This allows the user to change an authorization which has already been entered. 

2.2.3.2 The user nav igates, withi n the Ticket o r the Reservation, to the Bill-to area. 

2.2.3.3 The user indicates that s/he wishes to change the amoun t of an authorization for Bill-to. 

2.2.3.4 If the user wants to change an existing amount for dates which have already been authorized. 
s/he indicates the authorization that s/he wishe s to change and changes it. Because ARMS 
authorizations cannot be chanced bv the user, the system should not make anv ARMS 
authorizations available to them. 

2.2.3.5 The system automatically enters the details of the authorization into the reservation or ticket 
notes detailing the Enterprise employee who performed the authorization as well as all of the 

£1 associated details. * 

. >!■ _n 1 

M 2.2.3.6 The use case ends. 

2.2.4 Extend Authorization 

If 2.2.4.1 The user navigates, within the Ticket or th e Reservation, to the Sill-to area. 

]{ 2,2.4.2 The user indic ates that s/he wishes to extend an^uthonzation for a specific Bill-to. The user 
f 1 should not have anv authorizations available to them which are ARMS authorizations. 


2.2.4.3 The system presents the user with the end date of the most recent authorization amount and 
allows them to change it 

2.2.4.4 If the user wishes to change th e authorization amount, go to the Change Authorization alternative 


2.2.4.5 The user changes the end date to a date la ter than the date already in the authorization. IfJbjv, 
enter a date which is the same as the date already entered, then the use case ends. 

2.2.4.6 If the user attempts to change an end date for an authorization which has b een "Last Paved". 
then the system presents the user with an info rmational message and asks them to confirm the 
change, if thev confirm, then the Last Dav Date is updated accordingly. The authorization status 
remains "Terminated". 

2.2.4.7 The system automatically enters the details of the authorization into the reservation or ticket 
notes detailing the Enterprise employee who performed the authorization as well as all Of the 
associated details. 

2.2.4.8 The use case ends. 



within the Ticket or Reservation, to the Bill-to area. 

The system provides the option to indicate that the end date of the authorization is final and 
cannot be changed. If the authorization is an ARM S authorization this option is not available 
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and the use c ase ends. 

2.2.5.3 The user elects to make th e end date o f the authorization the LAST DAY. 

2.2.5.4 The system automatically changes the authorization status to 'Terminated" and enters the details 
of the authorization into the reservation or ticket notes detailing the Enterprise employee who 
performed the LAST DAY authorization as well as all of the a ssociated details. 

2.2.5.5 The use case ends. 

2.2.6 Remove Authorization 

2.2.6.1 The user naviqates 1 within the Ticket or Reservation, to the Bill-to area. 

2.2.6.2 The user Indicates that s/he wishes to remove a single authorization for a specific Bill-to. if the 
authorization is an ARMS authorization, this option is not available and the use case ends. 

2.2.6.3 Ibfijastemjiresente an option to the use r to cancel their choice, along with ail of the details of 
the authorization they selected. The details include which item(sl the authorization applies to and 
the amount and dates covered. 

2.2.6.4 User elects to continue. If thev elect to cancel, the use case ends. 

2.2.6.5 I f the authorization thev selected to remove is the only one on the ticket or reservati on for that 
Bill-to. then the system requires changes the authorization status to "Declined" but allows the 
user to change the authoriz ation status to "Pending". 

2.2.6.6 The syste m automatically enters the details of the authorization removal into the reservation or 
tic ket notes detailing the Enterprise em plo yee who performed the authoriz ation a$ well as all of 
the associated details. 

2.2.6.7 The use case ends. 

2.2.7 Remove all authorizations for a Bill-to Account 

2.2.7 .1 The user navigates, within the Ticket or Reservation to the Bill-to area. 

2.2.7.2 The user indicates that s/he wishes to remove all autho rizations fo r a specific Bill-to bv changing 
the authorization status to "Declined" . If the authorization is an ARMS authorization, this option 
is not available and the use case ends. 

2.2.7.3 The system p resents an option to the user to cancel their ch oice, along with all o fifag_deta|ig^ 
the^auftOrizat ions. The d eiailaiaciude w hich itemfs^ the authorizations apply to and the amounts 
and dates covered. 

2.2.7.4 User elects to continue. If thev elect to cancel f the use case ends. 

2.2.7.5 The system automatical ly enters the details into the reservation or ticket notes detailing the 
Enterprise employee who performed the authorization as well as all of the associated details. 

2.2.7.6 The use case ends. 

2.2.8 Account not on file 

2.2.8.1 The user navigates, within the Ticket o r Reservation, to the Bill-to area. 

2.2.8.2 The user indicates that s/he wishes to bill an ac count which is not in the system. 

2.2.8.3 The s ystem presents fields to enter the name of the account, the billing address information. 
phone number and name of a contact for that account All of the info rmation is recuired. Ib§ 
address entr y should follow the system standards which allow for the user to en ter the zip code 
and addres s and have the system search for the appropriate citv and state. If many citv. state 
combinatio ns are valid, the user should be a llowed to s elect from them. 
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2.2.8.4 The user completes all of the information. If they omit any part of the information and try to 
continue, the system provides a feedback message indicating which informat ion is missing. The 
system allows the user to update those items. 

2.2.8.5 The system does not ad d this accoun t to the account database. 

2.2.8.6 The system automatically enters the details of th e addition of the "Not on file" accou nt into the 


reservation or ticket notes detailing the Enterprise employ ee who performed the action as well as 
all of the associated details. 

2.2.8.7 The use case ends. 

2.2.9 Adding Required Billing Information 

2.2.9.1 The user navigates, within the Tick et or Reservation, to the Bill-to area. 

2.2.9.2 The user indicates that s/he wishes to ad d "Required Billing Information" 

2.2.9.3 The user indicates the account for which thev want to add or update the information. AQJ£ 
information associated with bili-tos on the ticket which have at least one ARMS authorization 
associated to it cannot be chanced and therefore, those accounts shouldn't be available to the 

2.2.9.4 The system makes the Claim/PO/RQ and Insured N ame fields a vailable for edit. 

2.2.9.5 If the account has listed at least one of these fields as required and/or that specific formatting is 
necessary, t hen the sys tem indicate s which fieldfo is reguired and/or the format that the 
i nformation must be in (if specified). » 

2.2.9.6 The user enters as much information as is available. (The information isn't reouired until the 
ticket is closed.) 

2.2.9.7 The system automaticall y enters the d etails of the information, into the reservation or ticket notes 
detailing the Enterprise employee who performed the edit as well as all of the associated details. 

2.2.9.8 The use case ends. 

3. Special Requirements - Bill-to 

3.1 Number of users 

Only one user should be allowed to update authorizat ion information on a ticket or 
reservation at a time. 

Onl y one user should be allowed to add or remove bill-to account numbers on a ticket or 
reservatio n at a time. 

3.2 Callbacks 

Anv update to authorizations should be taken into account bv the callbacks engine in 
generating callbacks to ren ters and Bfll-tos. 

3.3 Uiie 

If hel p text will be made available to the users, some expl anation of whv AEMS-authorized 
bill-tos are treated differently will be necessary. 

3.4 Authorization bv car class 

When the user is adding an authorization amount thev must b e allowed to look up the 
amount usi ng; a car class. Furthermore, if the retrieved rate is tiered, then the user must 
have the option either to select one of the rates or to indicate that the authorization is tiered 
and thereby associate all of the rates to the authorization. 
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3.5 ARMS auth orization 

Only one ARMS authorized account can be on a ticket/ reservation at a time. 

If a bill-to account receives an ARMS authorization and it is not in the bill-to ONE position, it 
must be changed to bill-to one and the other bill-tos must follow it Therefore, if bill-to one is 
Joe's Body Shop (non-AMRS) and bill-to two is Allstate (ARMS) and Allstate sends an initial 
ARMS authorization, it becomes bill-to one and Joe's Body Shop becomes bill-to two. 
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Version: <1.0> 


Open Retail Ticket without Payment 


Date: <dd/mmm/yy> 


<document identified 


5. 


Pre-Conditions 
User logged In 

The user must be logged in to the reservation or ticket system. 


5.1 


6. Post-Conditions 

6.1 None - 

7. Extension Points 

7-1 None 

8. Questions 

8.1 Rate source 

How is adding a bill-to (or removing one) expected to impact the reservation or ticket's rate source? If no 
impact, should a message be provided to the user? 

8.2 European requirements 

European requirements still need to be documented. When will these be available? 

8.3 ARMS 

Can the user change any Bill-to information on an ARMS ticket? 

8.4 System generated notes 

What details should be included in each note? 

8.5 Name of authorizer 

Should this name be free-form text or should a list of contacts for the account be used? If a list is optimal, 
then do omit the contact for "Not on File" bill-tos? 
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Revision History 


Date 

Version 

Description 

Author 

05/01/2001 

1.0 

Initial Draft 

David Beebe 

05/18/2001 

1.1 

1 st Revision (After break to work on Open 
Retail Rental Ticket without Payment Use Case) 

David Beebe 

05/23/2001 

1.2 

2 nd Revision 

David Beebe 

06/01/2001 

1.3 

Revisions based upon feedback from 
user review with Mary and Jon. 

1 . OK/Exit renamed to "Save" 

David Beebe 



2. Removed Age from the Personal 
Information Area. 


\ J 

HI 


3. Removed Insurance information 
from Rental Infnrmfltinn Arpa 


(J) 


4. Removed "Other Items Received" 
from Rental Information Area. 


5 


5. Added Employee Number/password 
authorization in the basic and 
alternate flows. 


[ah 

3 5 3 
I J? 


6. Renter Information entered or 
changed in this form makes 
changes to the corresponding renter 
or additional driver information. 



7. Added Supervisor's Phone Number 
to the Rental Personal Information 
Area. 


06/07/2001 

1.4 

Revisions based upon feedback from 
Reservation team. 

1 . Combined Personal and Rental 
Information Areas into one. 

2. Removed the following fields: First 
Name, Last Name, Social Security 
Number, Date of Birth, Street 
Address, Zip/Postal Code, Country, 
City, State/Province, Other 
Ownership, Home Phone Number, 
Work Phone Number, Other Phone 
Number (and phone type), 
Previous Address #1 and #2, 
Previous Employment Information, 
Spouse Employment Information, 
Credit Check Information. 

David Beebe 
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*| 
- * 


3. Also removed the corresponding 
Alternate Flows: No Match to 
Zip/Postal Code, Multiple City 
Results, Missing Name Information 
and Invalid Characters. 

4. Added the following fields: 
Insurance Company Name, Agent 5 s 

iNdme, Mgenis rnone iNUmDer ana 
Policy Number. 

5 Ppi^^wnrH a.nH Fnrmlrw/AA Mam a ic 
w. raocvvuiu auu ciupujycc; iNctuiw 1« 

oniy recjuirea wnen entering oasn 
Qualification Information during the 
Ticket process. 

6. Take out Suoervisor's Phone 
Number. (Todd Shylanski 6/13/01) 


3D6/21/2001 

1.5 

1 . Removed the following fields: 

David Beebe 



Insurance Company Name, Agent's 




Name, Agent s rnone Number and 


:r ? 
: 


Policy Number 


.1, 


2. Added (Blank) as an option for the 


11 


following fields: 


11 
II 


Ownership 




Rented Previously 


)S r, 


Do You Own a Car? 
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Use Case Specification: Enter Cash Qualification 

Information 

1- Enter Cash Qualification Informati on Use Case 
1.1 Brief Description 

This use case will describe how the user and the system interact to input cash qualification 
information concerning renters and/or additional drivers. It will show the flow of events that 
occur when information is input and/or selected in this area. 

2. Flow of Events 

2.1 Basic Ftow 

2. 1. 1 Cash Qualification Information Area 

The Enter Cash Quali fication Information Use Case be gins when the system d isplays the area 
for entry and selection of information about the person being cash qualified and the rental, The 
fields in this area are: 

• How Long at the current address: 
° Years 

o Months * 

• Ownership: 
o fBiank^ 
o Own 

o Rent 

• Current Employer 

• Position 

• Supervisor's Name 

• Spoke to W hom 

9 How Long at Current Job: 
o Years 
o Months 

• Reason for Renting 
o Car In Shop 

o Weekend 

o Vacation 

o Other 

o Other Reason Field 

« Previously Rented: 
o (Blank) 
o Yes 
o No 

o If So. When? 
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• Do You Own a Car?: 
o (Blank) 
o Y$s 

o Mg 


• Reference #1 
o First Name 
o Last Name 
o Phone Number 
o Relationship 


• Reference #2 
o First Name 
o Last Name 
o Phone Number 
o Relationship 


• Reference #3 
o First Name 
o Last Name 
o Phone Number 
o Relationship 


• Password 

• Employee Number 


There are no default values for any of the above fields. 


2.1.2 Option to Cancel 

The system displays the option for the user to cancel/exit . At anv ooint durina the entrv of cash 


qualification information the user could decide to cancel out of the entrv process at which time 
th_e use case would continue at alternate flow Cancel/ Exit. 

2.13 Option to Save 

The system displays the option to Save. At any point during the entry of cash qualification 
information the user coul d decide to Save, at which time the use case wo uld continue at basic 
flow^am. 

2. 1.4 Address and Ownership Information Selection 

The user can select how long the person being cash qualified has lived at the current address. 
The user can also select whether the person being cash qualified owns or rents. 
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2.1.5 Employment Information Entry and Selection 

• The user can enter the employment information about the person being 
cash qualified. They can enter the employer, the supervisor's name, the 
person being cash qualified employment position and whom the user spoke 
to when verifying. 

• The user can also select how long the person being cash qualified has been 
employed at their current job. 

2. 1. 6 Rental Information Entry/Selection 

• The user can select one or more reason(s) for renting. If the user selects the "other" option, 
the field for entry of information becomes available for entry. The user then enters the 
reason. 

• The user can select whether the person being cash qualified has rented before. If the user 
selects "Yes", the field for entry of information about when they last rented becomes 
available. The user then enters when the last rental was. (See Special Requirements for 
note.) 

• The user can select whether the person being cash qualified owns a car. 

• The user can enter the insurance company name, agent's name, agent's phone number 
and the policy number information about the person being cash qualified. 

2. 1 7 References Information Entry 

For all three references listed, the user can enter the First Name, Last Name, Phone Number 
and Relationship. 

2. 1.8 "Approved by:" Employee Number and Password Entry 

The user enters the Employee Number and password that approved the cash qualification. 

2. 1 9 Select Save Option 

The user selects the option to Save. 

2.1.10 Validation of Employee Number and Password 

The system validates the Employee Number and password that approved the cash 
qualification. If the user entered an invalid employee number and password combination the 
use case continues at alternate flow Invalid Employee Number and Password Combination . If 
the user entered an employee number and password that does not pass authority check the 
use case continues at alternate flow Authority Check Failed . 

2.1.11 Save 

The system saves all the information entered or selected in the fields of th e Cash Qualification. 
The saved information would include the following: 

• How Long at the current address: 
o Years 
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o Months 


• Ownership: 
o (Blank) 
o Own 
o Rent 


• Current Emplover 

• Position 

• Supervisor's Name 

• Spoke to Whom 

« How Lona at Current Job: 
o Years 
o Months 


• Reason for Rentinq 
o Car In Shop 
o Weekend 
o Vacation 
o Other 

o Other Reason Field 


• Previously Rented: 
o (Blank* 
o Yes 


o No 

o If So. When? 


• Do You Own a Car?: 
o (Blank) 
o Yes 
o Mq 


» Reference #1 
o First Name 
o Last Name 
o Phone Number 
o Relationship 


• Reference #2 
o First Name 
o Last Name 
o Phone Number 
o Relationship 


• Reference #3 
o First Name 
c Last Name 
o Phone Number 
o Relationshio 
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• The employee who selected to save the cash qualification information. 

2 1. 12 End 

The Use Case ends. 


2.2 Alternative Flows 

2.2.1 Cancel/ Exit 

2.2.1 . 1 The user selects the option to cancel/exit. 

2.2.1.2 The system displays a feedback message warning that the cash qua lification data will be lost if 
the user selects to cancel/exit. 

2.2.1.3 The syste m displays the following op tions: 

* Yes: to exit and lose data. 

• No: return to the cash qualification use case. 

(The default option will be No: return to cash qu alification.) 

2.2. 1 .4 The user selects Yes the use case ends. If the user selects No then continue in basic flow at 
the point where the user selected to cancel/exit 

2.2.2 invalid Employee Number and Password Combination 

2.2.2.1 The system displays a feedback message that the ente red Employee Number and p assword is 
invalid. 

2.2.2.2 The system prompts the user to enter a valid Emplo yee Number/password. 

2.2.2.3 The user selects to enter a valid Employee Number/password and returns to "Approved by" 
Employee Number and Password Entry . 


2.2.3 Authority Check Failed 

2.2.3.1 The system displays a feedback message that the employee is not allowed to authorize cash 
qualification. 

2.2.3.2 The system prompts the user to enter a valid Employee Number/password. 

2.2.3.3 The user selects to enter a valid Employee Number/password and returns to "Approved by" 
Employee Number and Password Entry . 


3. Special Requirements for Enter Cash Qualification Information 

"Do You Own a Car" Text Fields 

These fields could be left bl ank: there is no validation to make sure information was entered. 
Previously Re nted Text Field 

The user can enter whatever thev want to. Thev could enter things like "Last summer. "A few 
months aoo". Thev could also enter date inf ormation like "April 2000" or a more formal date like 
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"04/24/2001". The field could also be left blank: there Is no validation to make sure information 
was entered. ~ * " ^ 


Password and Employ ee Number 

The system requires password and employee number verification when cash 
qualification information is entered during the open ticket process. The system 
will not require password and employee number verification during the 
reservation process. 


4. Pre-Conditions 

A user is already authorized through a login process to access the panel that is necessary to: 

• Create or edit a reservation. 

• Open, edit or close a rental ticket. 

5. Post-Conditions 

6. Extension Points 

7. Questions 

Question: How should the Employee Number Approval field work? Should this field be: 

1. Automatically populated (and display only) based upon the user that is currently logged on 
and opening the ticket? (This assumes person opening ticket is also doing the cash 
qualification.) 

2. Automatically populated based upon the user that is currently logged on and opening the 
ticket but able to be changed? (This assumes person opening ticket is also doing the cash 
qualification but also allow changes.) 

3. Blank upon initial entry and allow entry of any employee (valid) number? (No assumptions 
about who is doing the cash qualification.) 

4. Blank upon initial entry and have security to authorize employee number? (This way a 
manager could "authorize" a cash qualification with security.) 

Answer: Since Cash Qualification information is a serious matter, the input from Jon and Mary 
is that the last choice is what they wanted. The user will need to enter a valid employee number 
and update code combination. However this will only be required for an open ticket. 


Question: What European requirements are there? 

Answer: Jon Jouris has indicated there could be translations for the U.K., Germany etc. Fields 
could be eliminated or labels could changed. 

As of 06/01/2001: once the feedback from the review has been integrated, an electronic copy of 
this document will be forwarded to the proper parties for European requirements and 
translations. 
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Use Case Specification: Notes 

1. Notes Use Case 
1.1 Brief Description 

This use case describes how the user interacts with the system to view ail notes 
associated to a ticket or reservation, select to view certain types of notes, add a 
new note or view the full details of a previously entered note. 

2. Flow of Events 

2.1 Basic Flow 

2.1.1 Selection to View Notes 

The Notes Use Case begins when the user navigates to the Notes area of a reservation or ticket. 
This could ta ke piace at any point in the reserva tion and ticket process. (Notes can be viewed at 
any point in the ticket process: when c reating a reservation, editing the reservation, opening a 
ticket using t he reservation, editing the open ticket, closing the ticket and after the ticket is 
dosed Notes will carry forward from a reservation to a ticket when a ticket is opene djuMPCLM 
reservation.) * 


2.1.2 System Searches for Notes 

The system searches for and r etrieves all notes associated to the reservat ion or ticket . 


2. 13 System Displays Notes Summary 

The system displays the notes to the user in a summary list On initial entry to the Notes 
Summary List the syst em will dis play all note s, regardl ess of tvoe. sorted from the newest to the 
oldest b y date and time. The columns displayed to the user are the following: 

• Date and Time (when th e note was saved^ 

• Note 

• Status 

o Reservation 
o Open 
o Close 

• Note Tvoe 

o Reservation 

o Shop 

o Bill-To 

o Renter 

o System 

o Callback 
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• Created Bv 

• ARMS message status: 

o (Blank) 
o Sent 


2. 1.4 Option to Add Note, View Note Detail, Print Notes and change displayed Note Types 
The system displays the options to select to: 

• Add a new note to the reservation or ticket. 

• View a single note that had been previously entered. 

• Print (either the Current Page or All Notes) 

• View notes of a particular Type and/or Status 

2.1.5 Add Note, View Note Detail and View Summary Based Upon Note Type Subflows 
Depending on u §gL&reference T he or sh e will use one of the follow ing three sub-flows: Add Note. 
Vi^NQfeJe tail and View Summary Based Upon Note Type . More commonly, the Add Note 
Sub-flow is used. If the user selects to print all Notes ( req ardteSJZLltot e type and Status) the 
use case continues at alternate flow Print All Records. 

2-2 Add Note Subflow 

2.21 Select to Add Note 

me^useLseJe cts to add a NotaJQibfij^e rvaBon or ticket . 

• (A Note can be added at any point in the ticket process: when creatin g a reservation, editing 
jhejBS^atLo n. opening aJLcket using the reservation, editing the open ticket closing the 
ticket and aft erjhe ticket is closed.) 

• System generated notes are defined in individual use cases. However thev will use the same 
write proce ss as ma nual Notes . 

2. 2. 2 Add Note Information Area 

The system displays the area f or the user to enter the Note. (Enhancement p rop osed for the 
future: System also displays the area fo r the user to select the Note Type. The possible Note 
Types are: Callback. Shop Bill-To and Renter.) 

2.2.3 Option to Save and Option to Cancel 
The system d isplays the option to- 

• Save 

• Cancel 

At anv point during the Add Note process the u ser could d ecide to exit at which time the use case 
would continue at alternate flow Cancel. (If the user cancels without making an entry, no 
feedback message will be displayed .1 

2.2.4 User Entry of Note 

The user enters the note. 
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2.2. 5 User Selects Option to Save 


The user selects to Save. 



2. 2. 6 Validation Note was entered 

The system v alidates that a note has been entered, if the system determines a note was not 
entered, the use case will co ntinue at alternate flow No Note. 

2. 2. 7 Save Add Note information 

The system saves the note. This system also saves information from the foliowinq areas: 

• Date and Time 

• Note 

• Status 

• Note Tvoe of "Callback" 

• Created Bv 

The user will not be able to select the Note Tvoe. date & time. Status and the 
"Created By" party. These items are determined and po pulated b y the system. 
(As stated above, future proposed enhancements will allow the user to select the 
Note Type.) 

2.2.8 End 

The system closes the Add Note area and the use case ends. 

2.3 View Note Detail SubflQW 

2.3. 1 Select to View Note 

The user selects to view the details of a single, previously entered note within the summary list of 
notes for the selected reservation or ticket. 

2.3.2 View Note Detail Area 

The system dis plays the Note Detail showing: 

• Date and Time 

• Note 

• Note Type 

• Created Bv 

• ARMS mes sage status : 

2.3.3 Option to Close View Note Area 

The syste m displays the option to close the are a that disp lays the det ails of a particular note. Ih§ 
system also displays the options to pr int the current Note. 

2.3.4 User Selects Option to Close the Viewed Note 

The user selects to close the View Note Detail area. If the user selects to print the current Note 
the use case continues at alternate flo w Print Note. 

2.3.5 End 

The system clos es the View Note Detail ar ea and the use case ends. 
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2.4 View Summary Based Up on Note Type Subflow 

2.4. 1 Select to View Summary Based Upon Note Type 

The user selects to the view notes summary of a certain note type. 

2.4.2 Display Possible Note Types and Ticket Status to sort from 

The system displays the list o f possible Note Types t o select to sort from: 

• AH 

» System 

• Internet Shoo 

(Future Proposed Enhancem ents will allow the user to s elect to also sort from Shop, Bill-To and 
Renter.) 

The system di splays the list of possible Ticket Status to Sort From 

• AU 

• Reservation 

• Open 

• Close 

2. 4. 3 Options to Print 

The system displays the option to: 

• Print Ail Notes 

2. 4. 4 User Selects Note Type 

The user selects a Note Type they want to view. 

2.4. 5 System Searches for Notes 

The system searches for and retrieves notes associated to t he ticket or reservation . 

2.4.6 System Displays Notes Summary 

The system displays the notes to the user in a sum mary list. The columns displayed to the user 
are the following: 

• Date and Time 

• Note 

• Note Type: based upon the type the user selected 

• Created By 

• ARMS message status 

2.4.7 Print 

If the user selects to print all Notes (regardless of the currently displayed Note Type) the use case 
continues at alternate flow Print All Notes. 
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2.4.8 End 


The use case ends. 



2.5 Alternative Flows 

2.5.1 No Note 

2.5.1.1 The system d isplays a fee dback message: "Please enter a Note if selecting to Save." 

2.5.1.2 The user ha s the option to: 

• Enter the note 

• Exit the Add Note process 

2.5.1.3 If the user selects to enter the note, use case proc eeds to Us er Entry of Note in the Sub Flow 
!Add Note", lithe user se lects to exit the Add Note process the use case ends. 

2.5.2 Cancel 

2.5.2.1 The system dis pjays^fee dback message: "Are you sure you want to exit an d lose the entemd 
information?" 

2.5.2.2 The user has the options: 

• Yes (exit and lose the information) 

• No (return to the use case at the point where the user selected to exit from.) 
The default option will be "No". 

2.5.2.3 if the user selects to exit the Add Note process, the use case proc e^J&S&g tem Displa ys Notes 
Summary in the Basic Flow . If the user selects No T the use case proceeds to Us er Entry of Nojg 
in the Add Note Subflow. 


2.5.3 Print All Notes 

2.5.3.1 The system initiates the Print Use Case 

2.5.3.2 The use case returns to the point where the user initia ted the print function. 

2.5.4 Print Note 

2.5.4.1 The system initiates the Print Use Case . 

2.5.4.2 The use cas e returns to the point wh ere the user i nitiated the print function. 

3. Special Requirements for Notes 

• Previously entered notes mav not be edited or deleted b y the user. 

• ystem generated and manually ent ered ) will be displayed based upon the date and time of 
the physical terminal location of the user viewing the notes. 
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4. Pre-Conditions 

• A user is authorized through a login process to create or edit a reservation or 
ticket. 

• The user has accessed a reservation or ticket, either in the process of editing 
or creating. 

5. Post-Conditions 

6. Questions 


Confidential 


©Enterprise Rent-A-Car, 2001 


Page 10 


Rental Redesign 

Version: 2.0 

Business Use-Case Specification 

Date: 12/21/01 

Y:\GROUPS\E-Commerce Group\Patent Materials 8 31 01\Copy of Ail 
Patents\ECARS20 - Open Ticket\Use Cases\Open Retail Rental Ticket Without 
Payment, doc 


Enterprise Rent-A-Car 


Rental Redesign/ECARS 2.0 
Business Use-Case Specification: Open Retail Rental 

Ticket without Payment 

Version 2.0 


CONFIDENTIAL 


©Enterprise Rent-A-Car, 
2001 


Page 1 


Rental Redesign 

Version: 2.0 

Business Use-Case Specification 

Date: 12/21/01 

Y:\GROUPS\E-CommerceGroup\PatentMaterials8 31 01\Copy of All 1 
Patents\ECARS20 - Open TickefAUse Cases\Open Retail Rental Ticket Without 
Payment.doc 


Revision History 


Date 

Version 

Description 

Author 

03/16/2001 

I .u 

Initial / 1 _ !i! ~ I ^ _ r i i _ _ 

initial uratt (initial creation of Use 
Case) 

David Beebe 

04/05/2001 

1.1 

Updating to make look and language 
like other Use Cases 

David Beebe 

05/10/2001 

1.2 

Version after reviews by System 
Analysts. 

David Beebe 

05/15/2001 

1.3 

Revision after feedback from Jeff, Todd 
and Systems Analysts 

David Beebe 

05/24/2001 

1.4 

Revision after reviews by Mary Schmitz 
and Jon Jouris 

David Beebe 

05/21/2001 

1.5 

Version as placed into Req. Pro 

David Beebe 

06/07/2001 

1.6 

Revision made to match "Basic 
Reservation" Use Case. 

1 . Split alternate flow "Under Age Soft 
Edit Restriction" into two alternate 
flows: Under Aae (18-20) Soft Edit 
Restriction and Under Aae (21-24) 
Soft Edit Restriction. 

Revision made to explain that matching 
Nat Res Reservation will be handled in 
a later iteration. 

2. Split alternate flow "Matching 
Reservations" into two alternate 
flows: Matchina Branch 
Keservation(s) ana Matcmnq Nat 
Res Reservationfs) 

David Beebe 

06/19/2001 

1.7 

Revisions made to "Selection from 
Units Not Rented List" alternate flow. 

1 . Added Buy Back Indicator to the list 
of information that should be 
returned. 

2. Added statement that the default 
sort order for the list will be 
alphanumerically by the Unit 
Number. 

David Beebe 

06/26/2001 

1.8 

Revision made to match "Basic 
Reservation" Use Case. 

1 . Split alternate flow "Expired 
Driver's License" into two alternate 
flows: Expired Driver's License and 

David Beebe 


CONFIDENTIAL 


©Enterprise Rent-A-Car, 
2001 


Page 2 


Rental Redesign 

Version: 2.0 

Business Use-Case Specification 

Date: 12/21/01 

Y:\GROUPS\E-Commerce Group\Patent Materials 8 31_01\Copy of Ail 
Patents\ECARS20 - Open Ticket\Use Cases\Open Retail Rental Ticket Without 
Payment.doc 




Driver's License Expires Todav. 


12/07/2001 

2.0 

Rewrote document. 

Dave Beebe 


CONFIDENTIAL 


©Enterprise Rent-A-Car, 
2001 


Page 3 


Rental Redesign 

Version: 2.0 

Business Use-Case Specification 

Date: 12/21/01 

Y:\GROUPS\E-Commerce Group\Patent Materials 8_31_01\Copy of All 
Patents\ECARS20 - Open Ticket\Use Cases\Open Retail Rental Ticket Without 
Paymentdoc 


Table of Contents 


O 

'.is* 
III 


1 , Open Retail Rental Ticket without Payment Use Case 6 
11 Brief Description 6 

2. Flow of Events 6 

1.1 Basic Row 6 
1.11 Search Criteria 6 

112 Options to Search, Clear/Reset and to select to Enter New Driver 6 

113 User Entry of Name and Phone Number 6 

114 User Selects Search Option 6 

115 System Performs Repeat Renter Search 6 

116 System Performs Reservation Search 7 

117 Reservation Search Results 7 

118 Repeat Renter Search Results 7 
j*J 119 Renter Personal Information Area 7 
f\ 1110 Option to Complete 8 
j*j 1111 Personal Information Area Field Population # 8 
W 1 . 112 Address and Zip/Postal Code Information Entry 8 
■!■ . 1113 Zip/Postal Code Search Option 8 
N 1 . 1 . 14 Zip/Postal Code Search Selection 8 
hI 11 1 5 Zip/Postal Code Search Results 8 
111 1.1.16City and State/Province Field Population 8 
111 1117 Phone and Driver's License Information Entry 8 
|l H18Cash Qualification, Renters Insurance and Additional Driver 9 
i?k 11 19 Referral Information 9 

1 120 Dates and Rates 9 

1121 User Selects Option to Complete 9 
1.1 .22 System Displays Complete Options 9 

1 .2 Complete Ticket Sub-Flow 9 

12.1 User Selects Complete Option 9 

1 .2.2 Validation of complete Renter Information 9 

1 .2.3 Validation of Driver's License Expiration Date Information 10 

1.2.4 Validation Of Date of Birth Information 10 

12.5 Validation Of Rate Information 10 

12.6 Other Validation 1 
1 .2.7 Incomplete Ticket Feedback Message 1 

12.8 Save Ticket Information 1 

12.9 Print Ticket 1 
!2.10End 1 

13 Complete Unit-Pend Ticket Sub-Flow 12 

1.3.1 Unit Pend Ticket 12 

13.2 User Selects Complete - Unit Pend Option ^ 2 

13.3 Complete Unit-Pend Ticket Validation 12 

13.4 Incomplete Ticket Feedback Message 12 

13.5 Save Ticket Information 12 
1.3.6 Print Ticket 12 

CONFIDENTIAL ©Enterprise Rent-A-Car, Page 4 

2001 


Rental Redesign 

Version: 2.0 

Business Use-Case Specification 

Date: 12/21/01 

Y:\GROUPS\E-Commerce Group\Patent Materials 8_31_01\Copy of All 
Patents\ECARS20 - Open TickeftUse Cases\Open Retail Rental Ticket Without 
Paymentdoc 


1.3.7 End 12 

1 .4 Complete Pre-Write Ticket Sub-Flow 1 3 

14.1 Pre Write Ticket 13 

14.2 User Selects Complete Pre-Write Option 13 

14.3 Validation of entry of Name 13 

14.4 Validation of Billing Cycle 13 

1 .4.5 Validation Of Date of Birth information 1 3 

1 .4.6 Incomplete Ticket Feedback Message 1 3 

14.7 Save Ticket Information 13 

14.8 Print Ticket 14 
1.4.9 End I 4 

1 .5 Alternative Flows 1 4 

15.1 Need More Search Criteria I 4 

15.2 Matching Branch Reservation(s) I 4 

1 .5.3 Matching Nat Res Reservation(s) 1 5 

1 .5.4 Matching Repeat Renter Record(s) 1 5 

15.5 Renter Warning/Do Not Rent 1 6 

15.6 No Match to Zip/Postal Code I 7 

15.7 Multiple City Results i7 

15.8 Other Address Information Entry * 17 

15.9 Expired Driver's License 1 8 

15.10 Driver's License Expires Today 1 8 

15.11 Over Age Soft Edit Restriction 1 9 
1 .5. 1 2 Under Age (1 8-20) Soft Edit Restriction 1 9 
1.5.13Under Age (21-24) Soft Edit Restriction 19 
15. 14 Under Age Hard Edit Restriction 20 
1 .5.1 5 Additional Driver 20 
15. 16 Cash Qualification Information 22 
15.1 7 Insurance Information 22 
1.5.18Cancel/Exit 22 

2. Special Requirements for Open Retail Rental Ticket without Payment 2 3 

3. Pre-Conditions 23 

4. Post-Conditions 23 

5. Extension Points 23 

6. Questions 23 


CONFIDENTIAL 


©Enterprise Rent-A-Car, 
2001 


Page5 


Rental Redesign 

Version: 2.0 

Business Use-Case Specification 

Date: 12/21/01 

Y:\GROUPS\E-Commerce Group\Patent Materials 8_31_01\Copy of All 
Patents\ECARS20 - Open Ticket\Use Cases\Open Retail Rental Ticket Without 
Payment.doc 


Business Use Case Specification: 
Open Retail Rental Ticket without Payment 


1. Qoen Retail Rental Ticket without P ayment Use Case 

1.1 Brief Description 

This use case will describe how the user and system interact to create a retail 
rental ticket. It will show the flow of events that occur when information is 
entered into a new retail type rental ticket so that it is completed. 

2. Flow of Events 

1.1 Basic Flow 

I. 1.1 Search Criteria 

The Qoen New Retail Rental Ticket Use Cas e heoins when the system displays the area for 
entry of search criteria for repeat renter information. The system display all search criteria 
fields blanked out, allowing the u ser to enter anv combination of the following information: 

• Phone Number 

• Last Name 

• First Name 

• Driver's License Number 

112 Options to Search, Clear/Reset and to select to Enter New Driver 

The system displays the option to select to pe rform the search from information entered in the 
above fields. The syste m also displays: 

• the option for the user to reset the e ntered information. 
to enter Ne w Driver informatio n 

1 13 User Entry of Name and Phone Number 

The user enters the renter's first and la st name and telephone number, (last name could 
either be iust the first coun le tetters or the complete last name^ If the user selects to enter New 
- Driver information the use case will continue at Sys tem Performs Reservation Search in the 
basic flow. 

114 User Selects Search Option 

The user selects the option to perform t he search. If the user only enters only the last name 
and selects to search, the use case will continue at Need Mo re Search Criteria alternate flow. 

I I. 5 System Performs Repeat Renter Search 

The system performs the search for matching rep eat renter information if a renter's telephone 
number was entered in the initial search criteria area. If information was not entered in the 
renter's telephone number ar ea, the use cas e will continue at Renter Personal Information Area 
in one of the subflows. 
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1.t6 System Performs Reservation Search 

The system searches for all the reservations that match the information entered. The search for 
the name will be a wildcard search. 


117 Reservation Search Results 

The system finds no matching reservations and the use case continues at the next step in the 
basic flow, if the search produces one or more matching branch reservation then continue at 
alternate flow Matching Branch Reservations). If the search produces one or more matching 
Nat Res reservation, then continue at alternate flow Matching Nat Res Reservation. 


118 Repeat Renter Search Results 

The s ystem p roduces no matching repeat renter records and t he use case continues at the 
next step in the basic flow. If the search produces one or more matching repeat renter match, 
then continue at alternate flow Matching Repeat Renter Recordfe). 


119 Renter Personal Information Area 

The system displays the area for entry and selection of information about the renter. The fields 

in this area are: 

Name: 

• Last Name 

• First Name 

Phone Number 

♦ Home Phone Number 

• Work Phone Number Tand extension) 

♦ Employer 

• Other Phone Number (and phone type) 

Home Address 

• Address 

* Zip/Postal Code 

* Country 

♦ State/Province 


Driver's License 

• License Number 

• Expiration Date 

• Issuing Country 

• State issued 

• SSN ^Soc ial Securi 

• Date of Birth 

• Eye Color 

• Height 

• Hair Color 
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Weigh tTha system also displays the ontion for the i iser to enter the wnrk address. If the user 
selects the option, the use case continues at alternate flow Work Address Information Entry. 


1. 1. 10 Option to Complete 

The system displays the option for the user tn complete the ticket. At any point the user couid 
select this option. 


1.1.11 Personal Information Area Field Population 

l Inless a reservati on or repeat renter informatio n has been applied to the ticket the system 
populates the ma tching fields with anv information previo usly entered in the hasic flow step 
I Jser Entry of Name and Phone Number. (See Special Requirements for table showing how 
information from the Initial Search Criteria Area fields is populated in the matching Renter 
Personal Information Area fields.) 

The system also makes the i nformation in the Information Area fields available for edit. ID§ 
country, based upon th e profile of the renting bre^h in^tinn will he defaulte d in t o the Count ry 

fi£l£L 


1.1.12 Address and Zip/Postal Code information Entry t 

The user enters t he Address and 7ip/Postal Code. 

1. 1. 13 Zip/Postal Code Search Option 

The system displays the option to search for the Ottv and State/Province based upon the 
7ip/Postal code and Country. 

1. 1. 14 Zip/Postal Code Search Selection 

The user selects the option and the sys tem performs the search for the City and State/Province 
that match the 7ip/Postal Corie and Country. 

1.1.15 Zip/Postal Code Search Results 

The system searches for and pr orinr.es a single City and State/Province result and continues at 
the next step in the basic flow. If the search produces no matching citv and State/Province 
information, the use case continues at alternate flow No Match to Zip/Postal Code. Jfjjg 
search produces multi ple cities, th e use case continues at alternate flow Multiple City Results,, 

1.1.16 City and State/Province Field Population 

The system populates the City and State/P rovince fields. The system also makes the 
information in these fiel ds available for edit. 

1.1.17 Phone and Driver's License Information Entry 

The user enters the home phone number, work phone number, other phone number and 
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selects the Work Address Potion. The use case continues at alternate flow Other Address 
Information Entry. 


1.1.18 Cash Qualification, Renter's Insurance and Additional Driver 

If cash qualification information need s to be gathe red about the renter, the use case continues 
at alternate flow Cash Qualification Information. If insurance detail information needs to be 


gathered about the renter the use case continues at alternate flow Insurance Information, if 


there are additional driver(s) and information needs to be gathered, continue at alternate flow 
Additional Driver. 

1.1.19 Referral Information 

This use case extends to the Referral use case for entry, validation and saving of all 
information concerning the Referral source. 

1.1.20 Dates and Rates 

This use case e xtends to the D ates/Rates use case for entry, validation and saving of all 
information concerning dates, rates, taxes and surcharges. While in the Dates/Rates area.the 
user selects a rental vehicle to be applied to the ticket 

1. 1:21 User Selects Option to Complete 

The user selects the op ti on to comp lete the ticket. 

1.1.22 System Displays Complete Options 

The system displays the o ption for the user to select the following type of complete tickets 

• "Complete" If the user selects "Complete", the use case 
continues at subflow Complete Ticket. 

. • 'Complete - Unit Pend" If the user selects "Comple te - Unit Pend". 
the use case continues at subflow Complete - Unit P end Ticket. 

• "Com plete - Prewrite" If the user selects "Complete - Prewrite". the use case 
continues at subflow Complete - Prewrite Ticket. 

1.2 Complete Ticket Sub-Flow 

1.2.1 User Selects Complete Option 

"Complete" option. 

1.2.2 Validation of complete Renter Information 

The system validates that information concerning the renter exists in ail of the followir 

Name: 

• First Name 

• Last Name 


Address: 
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« Address 

• Zip/Postal Code 

• Country 

• State/Province 


Driver's License: 

• License Number 

• License Expiration Date 

• State issued 

• Date of Birth 

• Sociai Security Number 

• Height 

• Weight 

• Hair Color 

• Eye Color 

12.3 Validation of Driver's License Expiration Date Information 

The s ystem valida tes that the information entered in driver's license expiration date field for the 
renter and additional drivers is greater tha n the current date. If user enters a drivers license 
expiration date that is les s than the cu rrent date, the use case continues at alternate flow 
Expired Driver's License . If the user enters a driver's license expiration date that is the same 
as the current d ate, the use ca se continues at alternate flow Driver's License Expires Today. 

1 2. 4 Validation Of Date of Birth Information 

The system validates that the Date of Birth for the renter and additional drivers is not greater or 
less than the restrictions for rental, if the user ente rs a Date of Birth that results in the renter's 
age being greater than the restrictions the use case continues at alternate flow Over Soft Edit 
Ace Restriction. If the user enters a Date of Birth that results in the renter's age being 18-20. 
the use case continues at alternate flow U nder Age (18-?^ Soft Edit Restriction. If the user 
enters a Date of Birth that results in the renter's ag* being 21 -?4. the use case continues at 
Under Ace (2 1-241 Soft Edit Restriction. If the user ente r a Date of Birth that results in the 
renter's aoe being le ss than the hard edit age restriction the use case continues at alternate 
flow Under Hard Edit Age Restriction. 

1.2.5 Validation Of Rate Information 

The system validates the necessary rate information is complete. 

• If there is a rate in the da il y field ther e must be a rate in the hourly field. 

• If there is a r ate in the wee kl y field ther e must be a rate in the daily field. 

• If there is a rate in the monthly field there must be a rate in the weekly field. 

• If there is a rate that either the unlimited mileage option is selected or that both the 
corresponding excess charge and unlimited mileage fields are completed. 

If the system determines tha t these reouirements are not met, the use case will continue at 
alternate flow Incomplete Rate Information. 
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12.6 Other Validation 

The system validates that a: 

• unit has be en selected (valid unit number and license p late or V1N number) 

• Date out and Time Outfields are populated with valid values 


1.2 J Incomplete Ticket Feedback Message 

If anv of the above area s and fields are missing information the system will present the user 
with a feedback message as to wha t re quired fields are not f illed to print a complete ticket. Ihe 
s ystem will display the option for the user to cancel the print action and re turn to the open ticket 
process, 

1.2. 8 Save Ticket Information 

The system s aves all the information entered in the fields of th e open ren tal ticket process. 
This would be information from the following areas: 

• Renter Personal Information 

• Cash Qualification, Renter's Insurance and Additional Driver Information 

• Referral Information 

• Rental Information * 

• Additional Product(s), Taxes and Surcharges 

The system saves other information that did not come from other use cases. This information 
would be: 

• Ticket Number 

• Employee number of person that opened the ticket 

• Group/Branch information 

• Information about the terminal the ticket was opened on 

Links will take you to the tables/locations in this document that contain the full list of items to be 
saved.) 

1.2.9 Print Ticket 

This use case extends to the Print Ticket Use case . 

1.2.10 End 

The use case ends. 
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1.3 Complete Unit-Pend Ticket Sub-Flow 


1.3.1 Unit Pend Ticket 

This suhflow is the same as the r.nmniete t icket except that white in the Dates/Rates area, the 
user rfoes not select a rental vehicle to he applied to the ticket. 

1.3.2 User Selects Complete - Unit Pend Option 

The user selects the "Complete - I init Pend" option. 

13.3 Complete Unit-Pend Ticket Validation 

The s ystem performs the same validation as th a Complete Ticket suhflow except that the 
system does not validate that a unit has heen selected. 

13.4 Incomplete Ticket Feedback Message 

If an y of the above areas and fields are missing information the system will present the user 
with a feedback message as to what required fields are not filled to Print a complete unit 
pended ticket. The system will display the option for the user to cancel tfie print action and 
return to the open ticket process. 

1.3.5 Save Ticket Information 

The system saves ail the information entered in the fields of the open rentalticket process.. 
This would be information from the following areas: 

• Renter Personal Information 

. Cash Qualification, Renter's Insurance and Additional Driver Information 

• Referral Information 

• Rental Information 

• Additional Product(s), Taxes and Surcharges 

The system saves other inform ation that d id nnt come from other use cases. This information 
would be: 

• Ticket Number 

• Employee number of person that opened the ticket 

• Group/Branch information 

• Information about the terminal the ticket was opened on 

Links will take you to the tables/locations in this document that contain the full list of items to be 
saved.) 

13.6 Print Ticket 

This use case extends to the Print Tic ket Use case. 

1.3.7 End 

This subflow and the use case ends. 
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1.4 Complete Pre-Write Ticket Sub-Flow 

1.4.1 Pre Write Ticket 

This subfiow is the same as the Complete tick et except that the user could only enter part of the 
needed information. While in the Dates/Rates area the user selects a hilling cycle and usually 
SgjgSfe a rental ve hicle to be applied to the ticket. 

1.4.2 User Selects Complete Pre-Write Option 

The user sele cts the "Compl ete Pre-Write" option. 

1.4.3 Validation of entry of Name 

The system vali dates that a first and last name has been entered fo r the renter. 

14.4 Validation of Billing Cycle 

This ygj £g§| evtends to the Dates/Rates Use Case to verify that a Billing Cycle has been 
§ejgctej£L * 

14.5 Validation Of Date of Birth Information 

he system validates that it is not greater or less than the restrictions for rental. If the user 
enters a Date of Birth that results in either the ren ter's or driver's age heina greater than the 
restrictions the use case continues at alternate flow Over Soft Edit Aae Restriction. If the user 
enters a Date of Birth that resu lts in either the ronton nr driver's age beinn 18-2.0. the use case 
continues at alternate flow Under Age H 8-201 Soft Friit Restriction. If the user enters a Date of 
Rirth that resul ts in either the renter's or d river's aae being 91-24. the use case continues at 
1 Inder Aae (21-74) Soft Friit Restriction. If the user enter 3 nato " f Rirth that rfiSlllts m eitner 
the renter's or driver's aae bein g less than the hard e dit age restriction the use case continues 
at alternate flo w Under Hard Friit Age Restriction, mate of Birth is not required for a prewrite, 
however if a date is entered it should he validated.) 

1.4.6 Incomplete Ticket Feedback Message 

■ If anv of the ahove areas and fields are m issing information the system will present the user 
with a feedhack message as to what required fields are not filled to print a complete prewrite 
ticket. The system will disnlav the o ption for the user tn cancel the nrint action and return to the 


open ticket process. 

1.4.7 Save Ticket Information 

The s ystem saves all the inform ation entered in the fields of the open rental ticket process. 
This would be information from the following areas: 

• Renter Personal Information 

• Cash Qualification, Renter's Insurance and Additional Driver Information 

• Referral Information 

• Rental Information 
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• Additional Product(s), Taxes and Surcharges 

The system saves other information that did not co me from other use cases. This information 
would be: 

• Ticket Number 

• Employee number of person that opened the ticket 

• Group/Branch information 

• Information about the terminal the ticket was opened on 


1.4.8 Print Ticket 

This use case extends to the Print Ticket Use case. 

1.4.9 End 

This subflow and use case ends. 

1.5 Alternative Flows 

1.5.1 Need More Search Criteria 

1.5.1.1 The system displa ys a feedback error mes sane that the last name cannot he the only search 
criteria and to enter at least o ne more criteria. 

1.5.1.2 The user se lects to ent er another pie ce of search criteria information and the use case 
proceeds back tn User Sel ects Search O ption in the basic flow. 


1.5.2 Matching Bra nch Reservation(s) 

152.1 If the syste m finds that the re is one or more current reservations based upon e i th er the re n t er 
first and last name, telephone number, date of hirth and driver's license number and 
State/Province the system should display all the reservations that match the information that 
The returned matched information list should include the following: 

Reservation Number 
Ranter First Name 
Renter Last Name 
Pickup Date 
Pickup Time 
Car Class 

Pickup Branch Location 
Date Reservation Created 
Date Reservation Last Modified 

1.5.2.2 The s ystem w ill present a list for the us er to select one of the displayed/summarized 

reservations. (See Special Requirements link for what reservations will not be displayed.) 

1 52 3 The user selects a reservation from the li s t and continue at Renter Personal Information Area 
in the basic flow. The user can al sn select at anv time to cancel out of the displayed list of 
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reservations. If a phone number was entered in the initial search criteria area the use case will 
continue at Repeat Rent er Search in t he basic flow If a phone number was not entered in the 
initial search criteria area the use case will continue a t Renter Personal Information Area -in the 
basic flow. 


15.3 Matching Nat Pes Reservation(s) 

15.3.1 In a later elaboration, the matching of a Nat Res Rese rvation to an onen ticket will be taken 


1.5.4 Matching Repeat Ranter Record(s) 

1.5.4.1 If the system finds that there one or more repeat renter records that match hased upon the 
telephone nu mber, the system should d is play all the repeat renter records that match the 
information that was input. The returned information list should include the following: 

• Renter First and Last Name 

• Street Addre ss Citv. State a nd Postal Code 

• Home Phone 

• Office Pho ne (and extension) » 

• Driver License Number 

• Driver License State 


• Date l ast Rented 


1.5.4.2 The system should also indicate if anv of th e repeat renter records on the above summary are 
nn the Renter Warning/Do Not Rent List. 

1.5.4.3 The system will present the option for the user to sel ect the repeat renter record to apply to the 
open ticket. 

15 4.4 The user selects a repeat renter record from the list. If the user selects a reneat renter record 
that is on the R enter Warning /Do Not Rent I ist. the use case will continue at alternate flow 
Renter Wamino/Do Not Rent. The user can s lsn select at any time to cancel out of the 
displayed list of repeat renter record s and continue at Renter Personal Information Area in the 
basic flow. 

1 545 The system displays the Renter Persona l Information Area with the information from the 
selected repeat renter record populated In the correct fields. The fields in this area and the 
information that could come from the reo^t renter record are: 

Name: 

• Last Name 

• First Name 

Phone Number 

• Home Phone Number 

• Work Phone Number fend extension 1 ! 

• Employer 

. Other Phone Number (and phone tvoe^ 
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Home Address 

• Address 

• Zip/Postal Code 

• Country 


• State/Province 



Driver's License 

• License Number 

• License E xpiration Date 

• issuing Country 

• State issued 

• Date of Birth 

• Soda! Security Number 

• Height 

• Weight 

• Hair Coior 

• E V e Color 

The system also displays the option to change the presented Repeat Renter Personal 
Information. 

1 5.4.6 If the user selects the option to change the presented Renter Personal Information, the use 

case continues at Address and Zip/Postal Code Information Entry in the basic flow . If the user 
does not select the option to change the presented Renter Personal Information, the use case 
continues at Cash Qualification, Renter's Insurance and Additional Driver in the basic flow. 


1.5.5 Renter Warning/Do Not Rent 

1.5.5.1 If the selected repeat renter record is on the renter warning/do not rent list the system displays 
a feedback message that the renter is on the Renter Warning List. 

1.5.5.2 The system displays the option for the user to: 

• Exit the ooen ticket process. 

• View the detailed Renter Warning information. 

1.5.5.3 The user sele cts to view the detailed Renter Warning information. If the user selects the exit 
the o pen tick et process op tion the use case continues at alternate flow Cancel/Exit. 

15.5.4 The system will display th e more detail ed information about the person along with messages 
about the warning. The warning must include the following: 

» Re peat Renter First and Last Name 

• Street Address 

• Ci^ 

• State 

• Postal Code 

• Home Phone 

• Office Phone fend extension) 
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1.5.5.5 
1.5.5.6 


Driver License State 
Date Of Birth 


Social Security Number 
Employer 

The ticket number and araup^nrh that the warning report was referenced to. 

The text infor mation from the report detailing whv the renter was placed on the warning/do 

not rent list. 

Reported by emplo yee name 
Reported bv em ployee number 
Reported bv employee title 

Reported bv employee phone number tend extension) 
Reported bv employee qrQUP/bra.octiJQcaJim 
Date ret 


The system displa ys the o ption to either rent nr do not rent. 

The user selects tn rent and the use case cont inue at Renter Personal Information Area in the 
basic flow If the user selects "Do Not Rent" the use case continues at alternate flow 
Cancel/Exit. In hnth rases t h » appropriate r^ntpr warning administrativewrnqrams Will be 


15.6 
1.5.6.1 

1.5.6.2 
1.5.6.3 


U Code 

The system displa ys a feedback m essage that the 7 ip/postal code and country combination 


does not produce matching c ity and state/prince information. 
The system prompts the us er tn manually enter citv and state/province information. 
The user selects tn manually enter citv and state/province information and the use case 
proceeds bac k tn Phone and D river's I icense Information Entry in the basic flow, 


15.7 Multi ple Citv Results 

1.5.7.1 The system disofaws a feedback m ^ssane that the 7ip/Pnstal Code and Country combination 
produces more than one matching citv. 

1.5.7.2 The system displ ay* the list of cities and nrompt$ the user to select a City. 

1.5.7.3 The user select s a Hitv from the l ist the use case proceeds hack tn City and State/Province 
Field Po pulatio n in the basic flow. 


15.8 Other Address Information Entry 

1.5.8.1 The system displays the area for entry and selecti on of other address information about the 
renter. The fields in this area are: 

• Address Type 

• Address 

• 7ip/postai Code 
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• Country 

• State/Province 

1.5.8.2 The country, based upon the pmfite cf the renting branch location, wiil he defaulted into the 
Country field . 

1.5.8.3 The user enters the Addre ss and Zip/Postal Code. 

1.5.8.4 The system displays the option to search for the city and State/Province based uoon the 
7i p/Postal Code and Country 

1.5.8.5 The user selects the option to nerfnrm the se arch for the Citv and State/Province that match 
the Zi p/Postal C ode and Country. 

1.5.8.6 The system searches for the f.ity anrl State/Province that match the Zip/Postal Code and 
Country. 

1 58 7 The system produces a single Citv and State/Province result and continues at the next step in 
the basic flow. If the search produces no ma tching citv and State/Province information, the use 
case continues at alternate flow No Match to 7ip/Postal Code. If the search produces multiple 
cities, the use case continues at altern ate flow Multiple Citv Results. 

1.5.8.8 The system populates the Cit y and State /Province fields. The system also makes the 
information in these fields available for edit. 

1.5.8.9 The system displa ys the opti on for the user to exit and return tn the basic flow. 

1.5.8.10 The user selects this option and the use case proceeds back tn Renter Personal Information 
Area in the basic flow. 

15.9 Fy pimd Drive r's License 

1.5.9.1 The system displays a feedback message th at the entered driver's license expiration date is 
invalid because it is less than the current date. 

1.5.9.2 The system p rom pts the user to: 

• Chanae/enter valid expiration date. 

• Fvit the open ticket process. 

1.5.9.3 if the user sele cts to change th e expiration date the use case proceeds back to Phone and 
Driver's License Information Fntry in the basic flow. If the user selects to exit the QPen ticket 
process the use case continu es at alternate flow Cancel/Exit. 

1.5.10 Driver's License Expires Today 

1.5.10.1 The system disnlavs a feedba ck message that the entered driver's license expiration date is 
the same as the current date. 

1.5.10.2 The system p rom pts the user to: 

• Continue with the open ticket process 

• Chanae/enter different expiration date 

• Fxit the ooen ticket process 

1.5.10.3 If the user selects tn continue with the open ticket process the use case continues at Cash 
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Qualification. Renter's insu rance and Additional Driver in the basic flow . If the user selects to 
chance the expiration date the use ca se proceeds hack to Phone and Driver's License 
Information Entry in the basic flow if tti« user selects to exit the open ticket process the use 
case continues at alternate flow Cancel/Exit. 


1.5.11 OverAae Soft Edit Restriction 

1.5.11.1 The system determines that the ana of the ren ter is equal to or greater than 70 years old. 

1.5.11.2 The system displays a feedbac k mess age that t he entered date of birth results in the age of 
the renter bein g over the a ge restriction. The system also displays the entered date of birth 
and the renter's aae. 

1.5.11.3 The system prompts the user to: 

• Continue with open ticket process. 

• Enter correct date of birth. 

• Exit the open ticket process. 

15114 If the user selects to continue with the open ticket process the use case continues at Cash 
Qualification. Renter's Insurance and Additional Driver in th e_basicJfflK. If the use r selects to 
chance the date of birth, the use case proceeds hack to Phone and Driver's License 
Information En tr y in the basic flow. If the user sele cts to exit the open ticket process, the use 
case continues at alternate flow Cancel/Exit. 


15.12 Unci fir Aae (18-20) Soft Edit Restriction 

1.5.12.1 The system determines that the ace of t he renter is 1fl to ?Q years old. 

15122 The s ystem disn lavs a feedback message that the entered date of birth results in the age of 
. the renter being under the aae restriction. The system also disnlavs the entered date Of birth 
and the renter's aae. 

1.5.12.3 The system p rnmnts the user to: 

• Continue with open ticket process. 

• Fnter correct date of birth. 

• Exit the open ticket process. 

15124 If the user selects to continue with the op en ticket process the use case continues at Cash 
Qualification and Renter's In surance in t he basic flow. If the user selects to change the date of 
hirth the use case proceeds back to Phone and Driver's Ucen *g information Fntrv in the basic 
flow. If the user selects to exit the open ticket process, the use case continues at alternate flow 
Cancel/Exit. 

1.5.13 Under Aae (21-24) Soft E dit Restriction 

1.5.13.1 The system determines that the ane of the renter is 21 to 24 years old. 

15132 The system disnlavs a feedhack messane that the en tered date of hirth results in the age of 
the renter beinn under the aae restriction. The system also displays the entered date of birth 
and the renter's aae. 

1.5.13.3 The system p rompts the user to: 

• Continue with open ticket process. 
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• Enter correct date of birth. 

• Exit the open ticket process. 

15.13.4 If the user selects to continue with the open ticket process, the use case continues at Cash 
Qualification and Renter's Insurance in the basic flow, if the user selects to change the date of 
birth, the use case proceeds hack to Phone and Driver's License Information Entry in the basic 
flow. If the user sel ects to exit the open ticket process, the use case continues at alternate flow 
Cancel/Exit. 

1.5.14 Under Aae Hard Edit Restriction 

1.5.14.1 The system determines that the aae of the renter is equal to or under the age of 1 7 years 

15 142 The system dis plays a feed back message that the entered date of birth results in the age of 
the renter being under the aae restriction. The system also displays the entered dste of birth 
and the renter's aoe. 

1.5.14.3 The system prompts the user to: 

• Correct the date of birth. 

• Exit the ope n ticket process. 

15144 if the user selects to change the date of birth, the use case proceeds back to Phone and 
Driver's License Information Fntry in the basic flow, ff the user selects to exit the open ticket 
process, the use case continues at alternate flow Cancel/Exit. 


1.5.15 Additional Driver 

1.5.15.1 The s ystem d isplays the a rea for entry a nd selection of information about the additional 
driver. The fields in this area are: 
Name: 

• Last Name 

• First Name 

Phone Number 

• Home Phone Number 

• Work Phone Number (and extension^ 

• Employer 

Other Phone Number (and phone tvoe) 

Home Address 

• Address 

• Zip/Postal Code 

• State/Province 
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• Expiration Date 

• issuinq Countrv 

• State Issued 
. Date of Birth 

• Social Securitv Number 


. Weiqht 
• Hair Color 



1.5.15.2 The system displays the option to search for the Reneat Renter Information for the additional 
driver based unon the home phone number. 

1.5.15.3 The user enters home phone number of the additional driver. 

1.5.15.4 The user selects the option a nd the system performs the search for matching repeat renter 
information. 

1.5.15.5 The system produces no matr.hinn reneat ranter records and the use case continues at the 
next step in this alternate flow. If the system produces one or more matching repeat renter 
records the continue at alternate flow Matchinn Repeat Renter Record(s). 

The user enters the first and l ast name of the additional driver. 

The system di s plays the oofinn for the use r tn select that the additional driver has the same 
address information as the renter. If the user sele cts this ontion. continue at 1.5.15,14. in this 
(alternated flow. 


1.5.15.6 
1.5.15.7 

1.5.15.8 
1.5.15.9 

1.5.15.10 

1.5.15.11 


The user enters the street address and 7ip/postal code. 

The system displa ys the ootipn to search for the Citv and State/Province based upon the 
7ip/Postal Code and Countrv. 

The user selects the option and the sys tem performs the search for the Citv and 
State/Province that match the Zip/Postal Cnrie and Country. 

The system searches for and prod. .r-.es a single City and State/Province result and 
continues at the next steo in this alternate flow. The system aisn makes the information in 
these fields a vailable for edit. If the search produces no matching citv and State/Province 
information, the use case continues at alte rnate flow No Match to Zip/Postal Code, jfjfcfi 
search produces multiple cities the use case continues at alternate flow Multiple City Results. 

1.5.15.12 The system populates the City and State/Province fields. The s ystem also makes t he 
information in th ese fields available for edit. 

151513 The user enters the home phone number, work phone numher other phone number and 
selects the other phone number type. The user also enters the Driver's I icense Number, 
Driver's License Fxpiration Date State issued Date of Birth Social Security Number. Height, 
Weioht. Hair Color and Eve Color. (See Special Requirements for list of "Other Phone Number 
Type.) The system also Hisniavs the nntinn for the user to selert/list the additional driver "with 

valid license". If the user selects this option, the use case continues at the next step in this 
alternate flow. 
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1.5.15.14 The system d isplays the a rea for entry o f additional driver's credit card information. The 
fields in this area include: 

• Credit Card Number 

• Credit Card Type 

• Name that appears on th e Credit Card 

• Expiration Date 

(There is currently no validation or processing of the entered credit card information.) 

1 5.15.15 If cash qualification information needs to be gathered about the additional driver, the use 
case continues at alternate flow Cash Qualification Information. If insurance detail information 
needs to be gathered about the additional driv er, the use case continues at alternate flow 
Insurance Information. 

1.5.15.16 The system d ispla ys the o ption for the user to: 

• Arid more ad ditional drivers. 

• Exit and return to the basic flow. 

151517 If the user selects to add more additional dri vers the system adds another blank additional 
driver area an d returns to the first ste p of thi s alternate flow. If the user selects to exit the use 
case returns to the noint in the basic flow where the use r selected to arid the additional driver 
information. * 

1.5.16 Cash Qualification information 

1.5,16.1 If the rental requires cash qualification information ahnut the renter or additional driver the 
use case extends to the Enter Cash Qua lification Information Use Case. 

Information 


If the rental req uires insurance information a hnut the renter nr additional driver the use case 
extends to the Enter Renter's/Ad ditional Driver's insurance Information Use Case. 

1.5.18.1 The user selects the option to cancel/exit. 

1.5.18.2 The system displays a feedba ck message warning that the entered data will be lost if they 

1.5.18.3 The system dis plays the following options: 

• Yes: to exit and lose data. 

• No: return to the use cas e the y just se lected to exit from. 

(The default option will be No: return to th e area where the user selected the 
Cancel option from.) 

1.5.18.4 The user selects Yes the use case ends. If the user selects No then continue in basic flow 3t 
the point where the user selected t o cancel/exit. 


CONFIDENTIAL 


©Enterprise Rent-A-Car, 
2001 


Page 22 


Rental Redesign 

Version: 2.0 

Business Use-Case Specification 

Date: 12/21/01 

Y:\GROUPS\E-Commerce Group\Patent Materials 8_31_01\Copy of All 
Patents\ECARS20 - Open Ticket\Use Cases\Open Retail Rental Ticket Without 
Paymentdoc 


2. Special Requirements for Open Retail Rental Ticket without Payment 

3.1 All lists in this document are the order that items should be placed. 

3.2 The information entered in the fields of Initial Sear ch Area will populate the fields of the Renter 
Personal Information the following manner: 

Initial Search Area 

Renter's Telephone Number = Hom e Phone Number 

Renter's Last Name L ast Name 

Ranter's First Name = First Name 

Driver's License Number = Driver's Lice nse Number 

3.3 I ist of Other Phone Number Tvoes: 


Home 
Work 

Cell/Mobile 



3.4 With the last name the system searches in the same group as the renting branch for a match on the 
teyt, appl ying from left to right on the number of characters f or records by the entered name. (There is 
an im plied wildcard at the end of the character set entered, but nn leading or imbedded wildcards 
within the character set) 

3.5 Later enhancements to the open ticket process will pre-populate information into the appropriate rate 
information fields. 

3.6 Tvoes of reservations not shown in th e list are as follows: 

• Voided reservations 

• Reservations that are attached to an open ticket. 

• Reservations that were attached to a ticket when it was closed. 

• Available reservations where the Pick-up date is greater than 5 calendar davs aao. 

3.7 If a user cancels out of the open ticket proc ess and a reservation had been previously applied, the 

reservation becomes a vailable again. 

3. Pre-Conditions 

A user is authorized through a login process to access the panel that is necessary to open 
ticket. 

4. Post-Conditions 


5. Extension Points 


6. Questions 
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Business Use-Case: Open Ticket Get Rates using Perot Engine(s) 

1. Open Ticket Get Rates 

1.1 Brief Description 

The purpose of this use case is to attem pt to describe what information must b e fed from the 
ECARS 2.Q syste m to the Perot Engines) in order to retrieve the appropriate rates for each 
product for the rental transaction, in this use case the products for which a rate is to be retrieved 
are the vehicle and all applicable coverag es, where offered (CDW. PAl and SLP). The ECARS 
2.0 system will provide the Perot system with s pecific information about the transaction in order to 
successfull y retri eve rates. This use case is specifical ly addressing a walk in. open ticket, rental 
transaction. 

2. Flow of Events 

2.1 Basic Flow 

2.11 Use Case Begins 

This use cas e should be able to be invoked from anywhere in the Open Ticket process and 
initiate the reguest for rates, for appropriate products (in this case vehicle and coverages^ from 
the Perot Enoinefs) for a specific rental transaction. (Eventually, this use case will evolve into the 
one, which is used to get rates for all functions. Reservatio n. Open and Pre-Write) 

2.12 Information Needed For Rate Retrieval # 

The ECARS 2.0 system will need to provide specific information from the transaction to the Perot 
system to retrieve rates. Perot will require specific information before it will be able to search for 
products and their associated rates. Below is the list of items the Perot system will need to 
retrieve rates for an open ticket: (Note: Perot has six engines it uses to get rates for various 
products. The Rate engine for Vehicle, the Charge engine for estimating and allocating charges, 
the Equipment engine for ancillary items such as child seat and ski rack, the Coverage engine for 
insurance coverages, the Ancillary engine for add on fees such as youthful driver and additional 
driver and the General conditions engine for providing messages and standard conditions.) 


• The pickup group and branch 

• The pickup date 

• The pickup time 

• The return cr oup and branch 

• The return date 

• The return time 

• The booking channel (reservation orig in) 

• The rental status (ticket status - re servation, open, closed. .A 

• The rate source (account number, acco unt name or default type) 

• The rental type (insurance , body shop, dealership, etc.) 

• The billing cvcie 

Note: There needs to be some wav that the user has the abilit y specify a start charges date 
and time that is different than the pick-up date and time. 
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Having values for all of the above items will allow the system to retrieve either a single rate plan 
or display all multiple r ate plans to the user so thev can c hoose whi ch one to use . Once a single 
rate plan ha s been selecte d, entering or selecting the following information will allow the system 
to show a rate bv product 


• The specific u nit (vehicle!, either a direct entry or selection from a listing of available 
units. 

• The option to display the car classes associated with the rate plan. 

• The coveraoe(s) (as related to car class) 


2.1.3 Pickup Group and Branch 

.Bv the time this use case is in voked, the sys tem should have already defaulted the pickup croup 
and branch to the terminal location group and branch 

2.1.4 Pickup dat e and time 

If the user has not entere d a pickup da te and time, then the system wil Ldgfau lt the date and time 
to current. The user can then have the ability to change it. 

2.1.5 Return Group and Branch 

The system shoul d default the return group an d branch to the same as the pickup group and 
branch and allow the user to edit or chance this. 

2.16 Return Date and Time 

The user is reouired to entered a return date and time. 

2.17 Booking Channel - Reservation Origin 

The reservation origin should be able to be distinguished by the system and have the appropriate 
value assigned by the system. 

2.1.8 Rental Status 

For this use case the status will be "Ope n" The system should be able to determine the status 
and assign the appropriate value for all instances of a rental transaction. 

2.1.9 Rate Source 

The user has either selected an acc ount name or account number to locate and assign a rate 
source, or has selected to use the default rates. 

2.1.10 Rental Type 

The user is required to select a rental type. 

2.1.11 Billing Cvcle 

The user is required to select a billing cvcle. 

With the above information entered into the system, selected by the user, or determined by the 
system, the Perot engine should be able to return any and all associated rate plans with a 
particular account. 

Tf there are multi ple rate plans (agreem ents^, the system should display this information 
to the user, an d provide a wav to select the appropriate one. Use case continues below. 
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If there is a single rate plan (agreement), the area is p o pulated with that plan textual 
description. 


2.1.12 Unit (Vehicle) Selection 

The system will allow the user to either enter a specific unit number or to have the ability to select 
one from a list of available units. 

2.113 Dis play ail Ca r Classes for Rate Plan option. 

The system will have a fe ature availab le which will allow the user to display all of the car 
classes associated with the s pecific rate plan selected a nd the corresponding rates for each 
car class. 

Once the user has selected a single car class the syst em will disp lay the units available for 
that car class. Wh en the user selects a vehic le OJmfL this use case continues below. 

2.1.14 Get Rates 

Once a specific unit has been identified or selected hv the user, there should be some 
mechanism to allow the user to specify to the system to get the rates. 

2.1.15 S ystem Returns Rates 

With all of the previously e ntered or syst em derived information, the system determines bv the 
specific unit, the rate and car class and returns the rate for the vehicle and the appropriate rate 
for all applicable coverages COW. PAl and SLP. 

The rate info rmation is presented to the user bv product for daily, weekly, monthly and hourly time 
periods. If a rate is not available for a time period, the system returns a value of zero. 

This information is displayed to the use r in a manner that allows editing or changing of the rates. 
An y changes in the rates w ill only apply to this specific rental transaction and will not be reflected 
hack in the rate plan. 

If the system can not find a ca r class, based an the unit, for that rate plan the use case continues 
at Car Class Not Present In Account Rate Plan. 

2.1.16 User Accepts Rates Returned. 

The system returns the rates for the time periods indicated for the vehicle, selected or indicated,, 
and all available coverages. CDW. PAl and SLP. The user accepts the rate without chances, 
informs the renter of the rates by product, and saves the transaction. 

The user also has an option to h ave the system to calculate total charges, for the selected 
products, over the duration of the rental This will invoke the estimated charges use case. 


The use case ends. 

2.1.17 Car Class Not Present In Account Rate Plan 

If the car class is not pres ent in the acc ount rate plan the system notifies the user of this and 
gives the user the option of using default rates, selecting a different car class within the specific 
rate plan, selecting a nother rate soum e or manually gOtgrjog in the rates for the vehicle and/or 
coverages. 

If another rate source is selected, default or another account the use case resumes at 2.1 .9. 
If another car class is selected within the specific rate plan, the use case resumes at 2.11 3._ 
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If the user manually elects to manually enter the rates there should be some function to allow 
this process. The rates will be saved with the ren^\ transaction. 


This use case ends. 
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3. Special Requirements 

3.1 If an y compo nent of the information needed for rate retrieval is changed which causes a chan 
in the rates for any item, a message is dis played to the user informing them of such. 

3.2 GPS Resp onse Time 

Our contracts with GPS systems reouire that a response be returned to a rate request within 
seven seconds. 

4. Pre-Conditions 

4.1 User must be logged on 

• The user is logged into ECARS 2.0 2.0 application and ECARS 2 0 has validated the 
user has privileges to perform rate verification. 

• The user ha s access to the local machine. 

• The user h as access to the network. 

5. Post-Conditions 

5.1 < Post-condition One > 

6. Extension Points 

6. 1 <Narne of Extension Point> 

7. Questions - all answered in initial business review. 
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Business Use-Case Specification: Open Ticket Search 

1. Open Ticke t Search 
1.1 Brief Description 

This use case will describe how a user interacts with a system to search for and locate an open 
ticket . It will show the flow of events that occur when a search is conducted to locate an open 
ticket. The system will search for and locate an open ticket (or more than one open ticket) based 
on the search criteria entered by a user. 

2. Flow of Events 

2.1 Rasir. Workflow 

2.1 .1 The use case begins when the user chooses to search for an open ticket. 

2 1 2 t im .11 The system displays all search criteria fields emptied out, allowing the user to enter 
specific search criteria (as can be seen in Tables A and B). I 1C1 1.2 This use case will default 
the grou p/branch location to the machine's p hysical location. The user may choose to search bv 
one, two or three (three being the maximum) o f these search criteria. The criteria does not 
include the group/branch. If a ticket number is entered as well as other criteria the system will 
only search for the ticket number and disreqar_dJi.ny other search criteria. * 

213 TABLE A The user will most commonly enter the fo llowing information: Renter last name Renter 
phone number s ) Ticket Number Note- The current group branch location always displays 

214 -TABLE B Other criteria the user mav e nter Unit num ber PO number RO number. Claim 
num ber (This is cu rrently in one field ) Account name (the user can search for a account name 
hased on. bill-to, sho p. Accou nt number (same as Account name] Renter First Name (along with 
Renter Last Name) Ticket Open Date Rental Vehicl e I icense Plate Number Search bv either a 
sinnle groun/hranch or entire group (This is the location that opened the contract.) Note: The 
current nronn branch location always riisnlavs The user mav search hv either account name or 
numher; notbv both. 


215 The use case continues with sub flows (Renter Last Name through Ticket Number ) for renter last 
name, renter home phone number, and ticket number (as shown in Table A). The use case can 
be read at any of these sub flows (a user is most likely to search by one of these criteria more 
often than the criteria identified in Table B). If the user chooses to search by criteria listed in 
Table B, the use case continues with the alternative workflows (No Ticket Found through Rentei 
Vehicle License Plate Number). 


2.2 RAnter Name-Snh Flow 

2.2.1 The user chooses to search for an onen tick et hv entering alphanumeric text in both the renter 
first and last name fields or just the last name field. 

22 2 The system searches for a match on the te xt annlvina from left to riaht on the number of 

characters for an open ticket hy the entered renter name. (There is an implied wildcard at the 
enri of the character set(s) entered hut no leading or imbedded wildcards within the character 
setis).) 
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2.2.3 The system produces and displays the result set if one or more tickets are found. 

2.2.4 if no o pen ti cketfsl are found with th e name entered, contin ue to aiterna te flow No Ticket Found. 
If the user enters oniv a firs t name continue at altern ate flow Renter First Name Only. 

2.2.5 The user selects to view the details of a single open ticket from the list and the use case ends at 
this point 


2.3 Renter Phone Number-Sub Flow 

2.3.1 The user chooses to search for an open ticket bv entering a renter phone number. (The number 
entered must be the full numbe r including area code.) 

2 32 The system searches for an open ticket with anv matching renter phone number regardless of the 
phone number tvoe. /Match must be exact: no wildcard search.) 

2.3.3 The system produces and dis plays the result set if o ne or more tickets are found. 

2.3.4 if no open ticket(s) is found with the phone number entered, continue to alternate flow No Ticket 
Found. 

2.3.5 The user selects to view the details of a single open ticket from the list and the use case ends at 
this point 


2.4 Ticket Number-Sub Flow 

2.4.1 The user chooses to search for an open ticket by entering a ticket number. 

2 42 The system searches for an open ticket with anv matching ticket number. (Match must be exact: 
no wildcard search.^ The system p roduces and displays the result set if one or more tickets are 
found. 

2.4.3 if no open ticket is found with the ticket number entered, continue to alternate flow No Ticket 
Found 

2.4.4 The user selects to view the details of a single open ticket from the list and the use case ends at 
this point. 
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3. Alternative Workflows 

3.1 Tir.ket Found 

3.1.1 If no open ticket is found based on either the last nam e, nhone number, ticket number, unit 

number. PO/RO/Claim number, account name, account number, t icket open date and the location 
entered the user can continue to 2.1 .3 in th p main flow or choose not tn perform another search 
and the use case ends. 


3.2 Renter First Name Only 

3.2.1 The user cannot search for an open ticket hy entering the ranter's first name and leaving the last 
name field blank. 

3.2.2 The system will not allow the user to enter a first n ame unless a last name is present 

3.2.3 The use case ends and co ntinues at the Renter Name sub flow. 

3.3 Pn/RO/Clatm Number 

3,3.1 The user chooses to search for an open ticket bv entering either a PO/RO/Claim number. 

3 32 The system searches for a match on the text , applyin g from left to right nn the number of 

characters for an open ticket by the ente red PO/RO/Claim number. The system produces and 
dis plays the result set if one or more tickets are found. 

3.3.3 If nn open ticket fst are returne d with the entered PO/RO/Claim number, the user can continue to 
alternate flow No Ticket Found. 

3.3.4 The user selects to view the details of a single open ticket from the list and the use case ends at 
this point. 

3.4 Unit Number 

3.4.1 The user chooses to search for an open ticket bv entering a unit number. 

3 42 The system searches for an open ticket with anv matching unit number. (Match must be exact; 
nn wildcard search.) The system prod uces and displays the result set if one or more tickets are 
found- 
No Ticket Found. 

3.4.4 The s ystem dis plays records found and the use case ends at this point. 

3.5 RiH-Tn/Shop Amount Name Search 

3.5.1 The user chooses to search for an onen tick et hv entering alphanumeric text in the account name 
field where the account could be the hill-tn and/or the shop. 
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3.5.2 The system searches for a match on th e text, a pplying from left t o rich! on the number of 
characters fo r an open ti cket bv the entered account name. (There is an implied wildcard at the 
end of the character set entered but no leading or imbedded w ildcards within the character 
sen The system produces and displays the result set if one or more tickets are found. 

3.5.3 If no open tic ket is return ed with the en tered referral source customer, the user can continue to 
alternate flow No Ticket Found. 

3.5.4 he user selects to view the details of a single open ticket from the list and the use case ends at 
this point. 

3.6 Account Number Search 

3.6.1 The user cho oses to search for an open ticket bv entering alphanumeric text in the account 
number field where the account co uld be the biii-to and/or shop. 

3.6.2 The s ystem searches f or an open ticket bv the entered acco unt number. /Match must be exact: 
no wildcard search. 1 ) The system produces and displays the result set if one or more tickets are 
found. 

3.6.3 If no open rick^t is returned w ith the entered account, the user can continue to alternate flow No 
Ticket Found. 

3.6.4 The user selects to view the details of a single open ticket from the list and the use case ends at 
this point. 


3.7 Ticket Open Date 

3.7.1 The user chooses to search for an open ticket containing by entering the date that the ticket was 
opened . 

3.7.2 The system searches for an open ticket by the entered ticket opening date. (Match must be 
exact: no wildcard search.) The system produces and displays the result set if one or more 
tickets are found. 

3.7.3 If no open ti cket is returned with the en tered ticket opening date, the user can continue to 
alternate flow No Ticket Found. 

3.7.4 When the u ser elects to search on a d ate for open contracts, the search will pull all contracts with 
an open contract date 1 dav prior through 1 day after the user specified date. 

3 J.5 The user selects to view the details of a single open ticket from the list and the use case ends at 
this point. 


3.8 Rental Vehic le License Plate Number 

3.8.1 The user chooses to search for an open tic ket containing by entering rental vehicle license plate 
number. 

3.8.2 The system searches for an o pen ticket bv t he entered entering rental vehicle license plate 
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number. (Match must be exact no wildcard search.) The system produces and displays the 
result set if one or more tickets are found » 

3.8.3 If no open ti cket is returned with the entered tick et o pening d ate, the user can continue at 
alternate flow No Ticket Found. 

3.8.4 The user selects to view the details of a single open ticket from the list and the use case ends at 
this point 


4. Special Requirements 

4.1 The user mus t have the abilit y to sort w ithin the table. 

5. Pre-Conditions 

5.1 A user is authorized through a login process to access the panel that is necessary to search for open 
tickets. 

6. Post-Conditions 

6.1 <Post-condition One> 

7. Extension Points 

7.1 <name of extension point> 

8. FAQ 

8.1.1 All the current search parameters are based upon an "AND" relationship. Should the system give 
the user the option to search by an "OR" relationship? 

8.1.2 Answer: No 
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Revision History 


Date 

Version 

Description 

Author 

06/03/01 

1.0 

First Draft 

M. Pallia 

6/6/01 

1.1 

Revisions based on the input of the 
Open Ticket team. Revisions included 
some wording changes as well as the 
removal of the most common 
navigation area flow. 

M. Pallia 

6/7/01 

1.2 

Changed document to notate that it is 
Account Name and Leaacv Customer 
Number 

M. Pallia 

6/8/01 

1.3 

The following changes were made 
during the user review: The basic flow 
was changed from entering a referral 
number to picking one from the Branch 
short list Changed name to Referral 
from Referral Call. A customer number 
is a Legacy Customer Number. 
Account search must have 2 criteria 
unless it is name or phone number. 
Finally added special requirements 3 
thru 6. 

M. Pallia 

6/12/01 

1.4 

Added the following requirement: 

• A new contacted cannot be added 
to a fleet type Account. 

Changed the following requirement 

• During the Account search, the 
user can select one or more 
account type or an all option. 

M. Pallia 

6/15/01 

1.5 

Replaced Legacy Customer Number 
with Account Number. Added a new 
section that is called Future Scope that 
details out the functional areas we will 
not be delivering for Pilot 

M. Pallia 

8/21/01 

1.6 

Version transferred from Reservation to 
Open Ticket Repository, 

D. Beebe 


Confidential 


©Enterprise Rent-a-Car, 2001 


Page 2 


Rental Redesign 

Version: 1.5 

Use Case Specification: Referral 

Date: 12/21/01 

Y:\GROUPS\E-Commerce Grcup\Patent Materials 8_31_01\Copy of All Patents\ECARS20 - Open 
TicketU tee Oases\Referral Use Case.UCS 

Table of Contents 


1 Referral Use Case 

4 

11 Brief Description 

4 

2. Flow of Events 

4 

2.1 Basic Flow 

2.2 Account Referral Sub-Flow 

2.3 Employee Referral Sub-Flow 

2.4 Alternative Flows 

4 

5 
6 

^ Sneeial Reauirements —Referral UC 

9 

4 Futurp Scone 

*t, I UlUlw wwpv 

10 

O. v I 55 wul lUiUL/HO 

10 

6. Post-Conditions 

10 

7. System Generated Notes -Referral 

10 

8. Extension Points 

10 

9. Questions 

10 


Confidential 


©Enterprise Rent-a-Car, 2001 


Page 3 


Rental Redesign 

Version: 1.5 

Use Case Specification: Referral 

Date: 12/21/01 

Y:\GROUPS\E-Commerce Group\Patent Materials 8_31 J)1\Copy of All Patents\ECARS20 - Open 
Ticket\Use CasesVReferral Use Case.UCS 


Use Case Specification: Referral 


1. Referral Use Case 

1.1 Brief Description 

This use case describes the interactions a user wiii take when a renter is referred to Enterprise by 
a promotional discount, an Account, a TV ad campaign or any other method of attracting Renters, 
or an employee of Enterprise refers a renter (Employees can refer themselves as well). 

2. Flow of Events 

2.1 Basic Flow 

2.1.1 This use case can be initiated at anv p oint during the Open Ticket process. 

2.1.2 Depending on the person making the O pen Ticket, the user wi ll use one of the two sub-fiows. 
More commonly, the Account Referral Sub-flow is used. 

2.2 Account Ref erral Sub-Flow 

2.2.1 The system displays an area for the user to select an Account from the Branch Short List. Ih§ 
system also gives the user the option to: * 

• Enter an Account Number, if the user chooses this option, the use case continues alternate 
(Account Number). 

• Search for an Account If the user selects this option, the use case continues at alternate 
(Account Search) 

2.2.2 The system retrieves and displays the Bra nch Short list The columns that are displayed to the 
user are ffrom lefttoriohtt: 

• Account name 

• Account Number 

• Account type 

• Owning Gr ou p and Branch 

• Address 


• State 

• as 

• Phone Number(s) 


If the physical terminal location is in Europe, the use case continues at Alternate (European 
Branch Short List). 

2.2.3 The user selects an acc ount from the list If the user does not choose an account from the list, 
the use case continues at (2.2.1) in the Account Referral Sub-Flow. 

2.2.4 The system retrieves and dis plays the following information: 

• Account name 

• Account Number 

• Account tvoe 

• Owning Grou p and Branch 

• Address 
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• State 

• Phone Numbers 

2.2.5 The user ha s the option to select an Account contact for the seiected account, select a different 
account or view the Account details of the selected account. If the user chooses to view "The 
Account Details", the use case continues at alternate (Account Details). If the user chooses to 
select a different account, the use case continues at alternate (2.2.1) within the Account Referral 
Sub-Flow. 

2.2.6 The user chooses to view the list of contact s for the sele cted account. 

2.2.7 The system dis plays the Account Contact list to the user If there are no Contacts identified for a 
particular Account, the use case continues at alternate (No Contacts). The column displayed to 
the user wi ll be the following: 

• Last Name 

• First Name 

2.2.8 The user ha s the option t o select a contact from the list or add a New Contact. If the user 
chooses to add a new contact, the use case continues at alternate (Add New Contact). 

2.2.9 The user selects a contact from the list. 

2.2.10 From here, the user can navigate to any other area within the Open Ticket 

2.2.11 The use case ends 

2.3 Employee Referral Sub-Flow 

2.3.1 The system displays an area for the user to perform the follo winO-QRtiQDSl 

• A field to en ter an Emplo yee Number 

• Search for an Employee. If the user chooses to search for an Employee, the use case 
continues at alternate (Employee Search) 

2.3.2 The user ty pes in an emp loyee number. 

2.3.3 The user initiates the search. 

2.3.4 The system checks the status of the search. If No Employee Matches are found, the use case 
continues at alternate (No E mployee Matches) If the search results in only one match, the use 
gase continues in this Sub-Flow. 

2.3.5 The system displays the following info rmation to the user 

• Employee Name 

• Group and Branch Number- Group and Branch Description 

• Department 

• Title 

2.3.6 From here, th e user can na vigate to anv other area within the Open Ticket. 

2.3.7 The use case ends 
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2.4 Alternative Flows 

2.4.1 Account Search 

2.4.1 . 1 From the Account Referral Sub-flow, the system dis plays an area with all the fields emptied out 
so that the u ser can enter se arch criteria . The fields that are available are: 

• Group. This includes an "All Groups" option. 

• Account Name 

• Account Ph one Number(s) 

• Account Type . This includes an "All" option. (See Special Requirements for the list 
of valid Account Types) 

2.4.1.2 The user enters an Account Name and selects "Air as the Account Type. 

2.4.1.3 The user initiates the search 

2.4.1.4 The system validates the search criteria. If only an account type is entered, the system will 
prom pt the user that at leas t one other criterion must be selected. If only a group is chosen, the 
system will prompt the user that at least one other criterion must be selected. 

2.4.1 .5 The s ystem checks the status of the search. If No Account Matches are found, the use case 
continues at alternate (No Account Matches). 

2.4.1.6 The system dis p lays the matches to the user in a summary list The columns that are displayed 
to the user are: (from left to right) 

Account name 
Account Number 
Account type 

Owning Group and Branch 
Address 
City 
§i§t§ 

Phone Numberfs) 

2.4.1.7 The user can do any of the followin g, options; 

• Select an ac count from th e summary list If the user chooses this option, the use case 
continues at (2.2.6) in the Account Referral Sub-flow 

• . Clear the se arch criteria. If the user chooses this option, the use case continues at (2.5.2. 1 ) 
of the Account Search Alternate. 

• Search again. If the user chooses this option, the use case continues at (2.5.2.2) of the 
Account Search Alternate. 

• ExiL If the user chooses this option, the use case continues at (2.2.2) in the Account 
Referral Sub-flow. 

2.4.2 Enter an Account Number 

2.4.2. 1 From the Account Referral Sub-Flow, the user chooses to enter an Account Number. 

2.4.2.2 The user types in an Account Number and initiates a search for ail the information associated 
with the entered Account Number. 

2.4.2.3 The system checks the status of the search . If No Account Matches are found, the use case 
continues at alternate (No Account matches), if More than one Account match is found, the use 
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case continues at alternate (More than One Account Match). If the search results in only one 
match, the use case continues at (2.2.5) within the Account Referral Sub-Flow. 

2.4.3 No Account Matches 

2.4.3. 1 From the Account Referral Sub-Flow, the system d is plays a message to the user letting them 
know that No Account Matches or records were found. 

2.4.3.2 The use case continues at (2.2.2) within the Account Referral Sub-Flow. 

2.4.4 More Than One Account Match 

2.44.1 The system displays a summary list of the matches to the user. The columns that will be 
displayed in the summary list are (from left to riohtt: 

Account name 
Account Number 
Account type 
Address 


State 

Phone Numbers 

2.4.4.2 The user has the option to select an acc ount from the list or to exit. If the user selects an 

Account from the list, the use case continues at (2.2.6) within the Account Referral Sub-Flow. If 
the user chooses to exit the list without selecting an Account, the use case continues at (2.2.2) 
within the Account Referral Sub-Flow. 

2.4.5 Account Details 

2.4.5.1 From the Account Referral Sub-Flow, the user cho oses to see the details about the selected 


2.4.5.2 The syste m displays an area that shows the following details abou t the Account: 

Account Details 

• Account Name 

• Account Number 

• Account Type 

• A^jJ.re$s 

• Ci^ 

• State 

• Zip Code 

• Phone Numberfs) 
Special Instructions 

• 2 "Hof lines 

• Miscellaneous Information 

• Discounts 

• Rules 

• Products 
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2.4.5.3 The user is done looking at the information and the use case continues at (2.2.6) with in the 
Account Referral Sub-flow. 


2.4.6 No Contacts 

2.4.6. 1 From the Account Referraf Sub-Flow, the system displays a mess age letting the user know that 
no contact have been set up for this Account 

2.4.6.2 The user can either add a new cont act or exit. If the user chooses to add a new contact, the use 
case continues at alternate (Add New Contact). If the user chooses to exit, the use case 
continues at (2.2.7) within the Account Referral Sub-flow. 

2.47 Add New Contact 

2.4.7.1 From the Account Referral Sub-Flow, the system displays an area for the user to enter Contact 
information. The fields th at can be ent ered are either: 

• Last Name 
And/or 

• First Name 

2.4.7.2 The user enters the fir st and/or l ast name and accepts the new contact information entered, if 
the user chooses to exit, the use case continues at (2.2.7) with in the Account Referral Sub-Flow. 

2.4.7.3 The system a ssociates th e new contact added to the Account chosen ancl the use case 
continues at (2.2.12) with in the Account Referral Sub-Flow. 

2.4.8 Employee Search 

2.4.8. 1 From the Employee Referral sub-flow, the user cho oses to search for an employee . 

2.4.8.2 The system displays an area with all the searc h criteria fields emptied out. The search criteria 
fields available for the us er to enter are: 

• Employee Last name 

• Employee First name 

2.4.8.3 The user enters a Last Nam e and a First name. 

2.4.8.4 The user initiates the search. 

2.4.8.5 The system checks the status of the search. If No Employee Matches are found, the use case 
continues at alternate (No Employee Matches). 

2.4.8.6 The system displays the matches to the user in a summary list. The columns that are displayed 
to the user area (from left to right) 

• Employee Name 

• Employee Number 

• Group and Branch Number with Group and Branc h Description 

• Department 

• Hflg 

2.4.8.7 The user can do anv of th e following options: 

• Select an employee from the summary list If the user chooses this option, the use case 
continues at (2.3.5) in the Employee Referral Sub-flow 

• Clear the search criteria. If the user chooses this option, the use case continues at (2.4.8.3) 
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of the alternate (Employee Search). 

• Search again. If the user chooses this option, the use case continues at (2.4.8.3) of the 
alterrtate (Empfoyee Search) 

• Exit. If the user chooses this option, the use case continues at (2.3. 1 ) in the Employee 
Referral Sub-flow. 


2.4.9 No Employee Matches 

2.4.9.1 From the Employee Referral Sub-Flow or the alternate (Employee Search), the system displays 
that no employe es match the c niBfiQ entered. 

24.9.2 The use case continues at (2.1.3) within the Employee Referral sub-flow or (2.4.8.2) in the 
alternate (Employee Search). 


2.4.10 European Branch Short List 

2.4. 1 0. 1 From the account referral sub-flow, the system retrieves an d displays the European Branch 
short list (NO TE: This lis t is comprised of all acc ounts that have an owning Group that equals 
the Grougoflh^Physicgl terminal's location.) The columns displayed to th e_jjser are: 

• Account Name 

• Account Number * 

• Account Type 

• Owning Group/ Branch 

• Address 

• QM 

• State 


• Phone Number^ 

2.4.10.2 The user selects an a ccount from the list that is displayed. 

2.4.1 0.3 The use case continues at (2.2.4) within the account referral sub-flow. 
3. Special Requirements -Referral UC 

1 . A contact must be selected for every Account that is selected as a Referral. 

2. The valid Account Types that are displayed to the user in Account Search are: 

o Body Shop 
o Corporate 
o Government 
o Fleet 
o Dealership 
o Insurance 
o Other 

3. For North America, the Branch Short List is currently bein g generated from the existing 
Leoacv system and is being stored in a table on the Oracle database. 

4. The system should not search or display for anv deactivated or deleted accounts. 

5. The user must have the ability to cancel a search at any time during the search. 
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4. 

5. 

5.1 
6. 
7. 

7.1 


Evil* 


6. An account and contact or an empl oyee numb er must be selected before the user can 
complete an open ticket. 

7. If a Fleet type Account is selected, the system should not allow the user to add a new 
contact. 

8. The system must allow the user to select one Accou nt Type or "All" during the Account 
Search. 

9. When a user adds a new contact, that contact mus t be saved to the database and be 
available fo r selection for anv future transactions. 

Future Scope 

The ability to view Account Details. Account Details includes the 2 "Hot Lines", Products, 
Miscellaneous Information, Discounts and Rules as set up in SI. 

Pre-Conditions 

The user successfully initiated the Open Rental Ticket Use Case 
Post-Conditions 

S ystem Generated Notes -Referral 

Notes should be gener ated when anv of the followin g eve nts occur * 


Note Text 


When to 
generate 


THiujser changes the Referral 

Affi-Qunt 


Referral Account "XXXXX" was changed to "XXXXXX" 


Edit 


)user changes the referral contact. 
(Tpfe referral account is the same) 


Referral Contact "XXXX" was changed to "XXXX" for Referral 
Account "XXXX" 


Edit 


THafeuser adds a "not on file" contact 


Not on File Contact "First Name, Last Name" was added for 
Referral Account "XXXXX". 


Create/Edit 


8. Extension Points 

9. Questions 
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Revision History 


Date 

Version 

Description 

Author 

07/10/2001 

1.0 

First Draft 

D. Beebe 

07/12/2001 

1.1 

Revisions based upon feedback from 
meeting with Mike P. and Jackie L. 

D. Beebe 

7/16/2001 

1.2 

Revisions based upon feedback from 
Mary S. and Jon J. 

• "Accident" changed to "Damage." 

• Removed steps for user choosing 
to search for make and model. 

o Once a user selects a Year 
the list of possible models 
are displayed. 

o Once a user selects a 
Make the list of possible 
models is displayed. 

• Removed requirement that the user 
must select full (year, make, model) 
renter vehicle information. 

• Removed enabling the "Other 
Make", "Other Model" and "Other 
Color" fields based upon selecting 
winer in in© iviai\.e , iviuuci anu 
"Color" fields. 

D. Beebe 

7/17/2001 

1.3 

Combined the Renter's Vehicle and 
Shop Use Cases back together. 

(In the GUI ECARS and the Functional 
Specs these two areas were combined. 
However when Ciber worked on the 
baseline code they were separated. 
Based upon feedback from Mary and 
Jon for ECARS 2.0 Renter's Vehicle 
and Shop were merged.) 

D. Beebe 
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7/24/2001 

14 

Updated "Add New Contact" to say that 
a user may enter the last and/or first 
name. The requirement previously 
stated that both were needed. 

D. Beebe 

7/30/2001 

1.5 

Added to Supplemental Requirements. 
Included all of the situations that the 
system should generate a note. 

D. Beebe 

8/2/2001 

1.6 

1 ) Added domains for "Type of Loss" 

2) Added to Supplemental Specs that 
the system should generate a note 
when the user changes the renter's 
vehicle. 

D. Beebe 

8/3/2001 

1.7 

1) Added alternate "European Branch 
Short List" when selecting a Shop. 

2) Added German Vehicle and Class 
information alternate flow. 

D. Beebe 

8/8/2001 

1.8 

Revision based upon feedback from 
Jon Jouris. Vehicle Notes will only be 
viewable from this screen and will not 
be saved to Notes. 

D. Beebe 

8/9/2001 

1.9 

Revisions based upon feedback from 
Chris Carr 

1 . Default values of drop downs is 
"Blank" 

2. Removed step to search for full 
account information after selection 
as shop: system already did this in 
previous step. 

3. Removed viewing full account 
details. 

4. When selecting a Not on File 
account , added functionality to get 
city and state from zip/postal code. 

D. Beebe 

8/14/2001 

2.0 

1 . Change Telephone to Phone. 

2. Only one type of loss can be - 
selected. 

D. Beebe 
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8/16/2001 

2.1 

1 . Corrected the "No Contact" 
alternate flow to remove EXIT 
option. 

D. Beebe 

8/20/2001 

2.2 

Changed name of use case from 
Renter's Vehicle/Shop to Vehicle/Shop 

D. Beebe 

08/28/2001 

2.3 

1 . Added "Zero Days" to list of "Theft 
Waiver Days". 

2. Added note that "Theft Waiver 
Days" is not displayed in all of 
Europe. 

3. Added note that the vehicle "Year" 
is not displayed in Europe. 

D. Beebe 

9/4/2001 

2.4 

1 . Added two European requirements 
for system generated notes. 

2. Vehicle Year field is not present in 
UK or Ireland. 

3. License plate field is removed. 

4. Registration number field for 
Europe added. 

5. Zero theft waiver days removed. 

6. Date of Loss not required. 

D. Beebe 

9/6/2001 

2.5 

Added what values are in the drop 
down for the class field in Germany. 

D. Beebe 

9/19/2001 

2 6 

Seoarated the three svstem aenerated 
notes for when the user changes the 
renter's vehicle Year, Make and/or 
Model. 

D. Beebe 

9/25/2001 

2.7 

Added Supplementary Spec noting 
what information the navigation should 
show. 

D. Beebe 
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10/23/2001 


2.8 


1 ) Removed system note the "Not on 
Fiie Account XXXX has been 
added as a Shop" 

2) Changed system note "Not on file 
contact XXXX was added for Shop 
Account XXXX to "Not on file 
contact XXXX was added for 
Account XXXX. 


D. Beebe 
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Use Case Specification: Vehicle/Shop 


1 . UC15 Vehicle/Shop Use Case 

1.1 Brief Description 

This use case describes the how the user interacts with a system to indicate the renter's type of 
vehicle that is being repaired, notes about the vehicle, whether the vehicle is driveabie, the type 
of loss, the date of loss and the theft waiver days. This use case also describes how the user 
interacts with a system to indicate which shop a renter's vehicle is being repaired at. 


2- Flow of Events 
2.1 Basic Flow 

2. 1. 1 Select Vehicle/Shop 

The Vehicle/Shop Use Case begins- when the user navigates to the Vehicle/Shop area of a 
reservation or ticket. This could be initiated at any point during the Reservation/Open Ticket 
process. 

2. 1 2 System displays the Select Vehicle, Loss Information and Select Shop Areas 

The system displays an area for the user to select and enter information about the vehicle. The 
fields displayed to the user are the following: * 

• Year (If the physical terminal location is in the U.K. and Ireland the system does not display 
this field.) 

• Make 

• Other Make 

• Model 

• Other Model 

• Color 

• Other Color 

• If the physical terminal location is in Europe the system also displays the field that allows the 
user to enter the registration number. 

If the physical terminal location is in Germany the system also displays the following field to the 
user: 

• Class 

o (1,2,3,4,5,6,7,8,9,10) 


(The Legacy/ECARS 1.0 system does not store the registration number or the 
"Schwackeliste" Class in Germany.) 

If the physical terminal location is in Germany also displays the following fields to the user; 

• Vehicle Type 

• Number of Doors 

• Fuel Type 

• Engine Size 

• Engine Power 

• Class 

The system also displays an area for the user to enter and select loss information about the 
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vehicle. The fields displayed to the user are the following: 


• Is Car Driveable?: 
o (Blank) 

o Yes 
o No 

• Type of Loss; 
o (Blank) 

o Damage 
o Theft 

• Total Loss 
o (Blank) 
o Yes 

o No 

• Date of Loss 

• Theft Waiver Days (If the physical terminal location is in Europe the system does not display 
this field,) 

o (Blank) 
o One Day 
o Two Days 
o Three Days 

The system also displays an area for the user to enter Notes about the Vehicle. 
The default values for the above fields is (Blank) 

The system displays an area for the user to select an account from the Branch Short List. The 
system also gives the user the option to: 

• Enter a Legacy Customer Number. If the user chooses this option, the use case continues 
alternate flow Enter a Legacy Customer Number. 

• Search for an Account. If the user selects this option, the use case continues at alternate 
flow Account Search. 

• Add a "Note on File" Shop to the reservation/open ticket. If the user selects this option, the 
use case continues at alternate flow Add Not on File Account. 

2. 13 User Decides to Search for Year 

The user initiates a search for the year a renter's vehicle was manufactured. 

2 14 System Searches for Vehicle Year 

The system retrieves and displays the list of years that a user may select from. 

2. 15 User Selects the Renter's Vehicle Year 

The user selects the year of the renter's vehicle. 

2. 1 6 System Searches for Make 

The system retrieves and displays the list of possible makes to choose from for the previously 
selected (vehicle) year. 

2. 1 7 User Selects the Make 

The user selects the make of the renter's vehicle. The user can also choose to select "Other" 
and/or enter text in the "Other Make" field. 

2.1.8 System Searches for Model 

The system retrieves and displays the list of possible models to choose from for the previously 
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selected make. 


2.1.9 User Selects the Model 

The user selects the model of the renter's vehicle. The user can also choose to select "Other" and 
enter text in the "Other Model" field. If the physical terminal location is in Germany, the use case 
continues at Alternate Flow German Vehicle and Class Information. 

2.1.10 System displays Colors 

The system retrieves and displays the list of colors to choose from. 

2.1.11 User Selects the Color 

The user selects the color of the renter's vehicle. The user can also choose to select "Other" and 
enter text in the "Other Color" field. 

2.1.12 User Enters the Vehicle Note 

The user enters the a note about the renter's vehicle. 

2. 1. 13 User Selects and Enters the Loss Information 

The user selects whether the car is driveable, the type(s) of loss and the date of loss. If the user 
selects "Theft" as a type of loss the use case continues at alternate flow Theft Waiver Days. 

2. 1. 14 User Selects to display Branch Short List 

The user selects the option to display the branch short list. t 

2. 1. 15 System displays Branch Short Ust 

The system retrieves and displays the Branch Short list. The columns that are displayed to the 
user are (from left to right). 
Account name 

Legacy Customer Number (called Account Number in ECARS 2.0) 
Account type 

Owning Group and Branch 
Address 
City 
State 
Zip 

Phone Number(s) 

If the physical terminal location is in Europe, the use case continues at Alternate Flow European 
Branch Short List. „ 
(If possible, any previously selected Referral or Bill-To source that is a Dealer ; Body Shop or 
"Other Account Type should be displayed at the top of the Branch Short List The rest of the 
Branch Short List should be displayed below that alphabetically.) 


2.1.16 User selects Account from Branch Short List 

The user selects an account from the list If the user does not choose an account from the list, 
the use case continues at alternate flow Account Search. 

2.1.17 System Displays Contacts 

The system displays the list of Contacts for the selected Account to the user along with 
"Unknown". (All Accounts have a listing of "Unknown" as a Contact) 
The column displayed to the user will be the following: 
• Last Name 
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• First Name 

If there are no Contacts identified for a particular Account besides "Unknown", the use case 
continues at alternate flow No Contacts. 


2.1.18 Option to Select Contact or Add New Contact 

The user has the option to select a contact from the list or add a New Contact. 

2.1.19 User Selects Contact 

The user selects a contact from the list. If the user chooses to add a new contact, the use case 
continues at alternate flow Add New Contact. 

2. 120 User Selects to Exit the Vehicle/Shop Area 

The user selects to exit the Vehicle Area/Shop. (From here, the user can navigate to any other 
area within the Reservation/Open Ticket) 

2. 1.21 Validation of the Date of Loss and Theft Waiver Days 

The system validates the value in the date of loss field. If a date of loss is not valid because: 

• The date does not exist (February 30) 

• The date is greater than today's date. 

the use case continues at alternate flow Invalid Date Value. 

2.122 End 

The use case ends. 
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2.2 Alternative Flows 

2.2.1 German Vehicle and Class Information 

2.2.1 .1 The system retrieves and displays the list of Vehicle Types that a user may select from for the 
previously selected model. 

2.2. 1 .2 The user selects the Type of the renter's Vehicle. 

2.2.1 .3 The system retrieves and displays the list of Number of Doors that a user may select from for the 
previously selected Vehicle Type. 

2.2.1 .4 The user selects the Number of Doors for the renter's vehicle. 

2.2.1 .5 The system retrieves and displays the list of Fuels that a user may select from for the previously 
selected Number of Doors for the renter's vehicle. 

2.2.1 .6 The user selects the Fuel type for the renter's vehicle. 

2.2.1 .7 The system retrieves and displays the list of Engine Sizes that a user may select from for the 
previously selected Fuel type for the renter's vehicle. 

2.2.1 .8 The user selects the Engine Size for the renter's vehicle. 

2.2.1 .9 The system retrieves and displays the list of Engine Powers that a user may select from for the 
previously selected Engine Size for the renter's vehicle. 9 

2.2.1 .10 The user selects the Engine Power for the renter's vehicle. 

2.2. 1 . 1 1 The system retrieves and displays the Class for the renter's vehicle. - ' 

2.2.1 .12 The use case continues at System displays Colors in the basic flow. 

Theft Waiver Days 

When the user selects "Theft" as a type of loss, the system enables the "Theft Waiver Days" 
field. 

The user selects the number of theft waiver days. 

The use case returns to User Selects to Exit the Vehicle/Shop Area in the basic flow. 
2.2.3 Invalid Date Value 

2.2.3.1 The system displays a feedback message that the "Date is invalid". 

2.2.3.2 The system prompts the user to correct the date. 

2.2.3.3 The user selects to correct the date and the use case returns to User Selects and Enters the 
Loss Information in the basic flow. 
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2.2.4 European Branch Short List 


2.2.4.1 The system retrieves and displays the European Branch short list (NOTE: This list is comprised 
of ail accounts that have an owning Group that equals the Group of the physical terminal 
location.) The columns displayed to the user are : 

• Account Name 

• Account Number 

• Account Type 

• Owning Group/Branch 

• Address 

• City 

• State 

• Zip 

• Phone Numbers. 

2.2.4.2 The user selects an account from the list that is displayed. 

2.2.4.3 The use case continues at User selects Account from Branch Short List in the basic flow. 


2.2.5 Account Search 

2.2.5. 1 The system displays an area with all the fields emptied out so that the user can enter search 
criteria The fields that are available are: 

• Group. This includes an "All Groups" option. * 

• Account Name 

• Account Phone Number(s) 

• Account Type. This includes an "Air option. (See Special Requirements for the l/st 
of valid Account Types) 

2.2.5.2 The user enters an Account Name and selects "AH" as the Account Type. 

2.2.5.3 The user initiates the search. 

2.2.5.4 The system validates the search criteria. (If only an account type is entered, the system will 
prompt the user that at least one other criterion must be selected. If only a group is chosen, the 
system will prompt the user that at least one other criterion must be selected.) 

2.2.5.5 The system checks the status of the search, if No Account Matches are found, the use case 
continues at alternate flow No Account Matches. 

2.2.5.6 The system displays the matches to the user in a summary list. The columns that are displayed 
to the user are: (from left to right) 

• Account name 

• Legacy Customer Number (called Account Number in ECARS 2.0) 

• Account type 

• Owning Group and Branch 

• Address 

• City 

• State 

• Zip 

• Phone Number(s) 

2.2.5.7 The user has the following options: 

• Select an account from the summary list. 

• Clear the search criteria. 
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• Search again. 

• Exit. 

2.2.5.8 If the user chooses to select an account from the summary list, the use case continues at System 
Displays Contacts in the basic flow. If the user chooses to clear the search criteria, the use case 
continues at the first step in alternate flow Account Search. If the user chooses to search again, 
the use case continues at the first step in alternate flow Account Search. If the user chooses to 
exit, the use case continues at System displays Branch Short List in the basic flow. 

2.2.6 Enter a Legacy Customer Number 

2.2.6.1 From the Basic Flow, the user chooses to enter a Legacy Customer Number. 

2.2.6.2 The user types in a Legacy Customer Number and initiates a search for all the information 
associated with the entered Legacy Customer Number. 

2.2.6.3 The system checks the status of the search. If No Account Matches are found, the use case 
continues at alternate flow No Account Matches. If More than one Account match is found, the 
use case continues at alternate flow More Than One Account Match. If the search results in only 
one match, the use case continues at System Displays Contacts in the basic flow. 


2.2.7 No Account Matches 

2.2.7. 1 From the basic flow, the system displays a message to the user letting them know that No 
Account Matches or records were found. 

2.2.7.2 The use case continues at System displays the Select Vehicle, Loss Information and Select 
Shop Areas in the Basic Flow. 

2.2.8 More Than One Account Match 

2.2.8. 1 The system displays a summary list of the matches to the user. The columns that will be 
displayed in the summary list are (from left to right): 

• Account name 

• Legacy Customer Number 

• Account type 

• Address 

• City 

• State 
. Zip 

• Phone Number(s) 

2.2.8.2 The user has the option to select an account from the list or to exit. If the user selects an 
Account from the list, the use case continues at System Displays Contacts in the basic flow. If 
the user chooses to exit the list without selecting an Account, the use case continues at System 
displays Branch Short List in the basic flow. 


2.2.9 Add Not on File Account 

2.2.9.1 The system displays an area for the user to enter Account information for an account that is not 
on file. The fields that must be entered are: 
• (Account) Name 
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• (Street) Address 

• Zip 

• Phone Number 

• City 

• State 

• Zip 

• Contact Last Name 

• Contact First Name 

2.2.9.2 The user enters the (Account) Name, (Street) Address, Zip/Postal Code and Phone Number. 

2.2.9.3 The system displays the option to search for the City and State/Province based upon the 
Zip/Posta! Code and Country. 

2.2.9.4 The user selects the option and the system performs the search for the City and State/Province 
that match the Zip/Postal Code and Country. 

2.2.9.5 The system produces a single City and State/Province result and continues at the next step in 
the basic flow. If the search produces no matching City and State/Province information, the use 
case continues at alternate flow No Match to Zip/Postal Code. If the search produces multiple 
cities the use case continues at alternate flow Multiple City Results. 

2.2.9.6 The system populates the City and State/Province fields. The system also makes the 
information in these fields available for edit 

2.2.9.7 The system associates the Not on File account to the reservation/ticket atfd the use case 
continues at alternate flow Add New Contact. If the user chooses to exit, the use case continues 
at System Displays Contacts in the basic flow. 

2.2.9.8 The system associates the new contact added to the Account chosen and the use case 
continues at User Selects to Exit the Vehicle/Shop Area in the basic flow. 

2.2.10 No Match to Zip/Postal Code 

2.2.1 0.1 The system displays a feedback message that the zip/postal code does not produce matching 
city and state/province information. 

2 2.10.2 The system prompts the user to manually enter city and state/province information. 

2.2.1 0.3 The user selects to manually enter city and state/province information and the use case 
proceeds back to 2.2.9.7 in the alternate flow Add Not on File Account. 

2.2.11 Multiple City Results 

2.2.1 1 .1 The system displays a feedback message that the Zip/Postal code produces more than one 
matching city. 

2.2.1 1 .2 The system displays the list of cities and prompts the user to select a City. 

2.2.1 1 .3 The user selects a City from the list and the use case proceeds back to 2.2.9.7 in the alternate 
flow Add Not on File Account 

2.2.12 No Contacts 

2.2.1 2.1 From the basic flow, the system displays a message letting the user know that no contacts have 
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been set up for this Account. (All Accounts have a listing of "Unknown" as a contact The 
message will display when "Unknown" is the only contact present) 

2.2.12.2 The user can : 

• Add a new contact. 

• Select a contact of "Unknown" 

2.2.12.3 1 If the user chooses to add a new contact, the use case continues at alternate flow Add New 
Contact. If the user selects a contact of "Unknown", the use case continues at User Selects to 
Exit the Vehicle/Shop Area in the Basic Flow. 

2.2.13 Add New Contact 

2.2. 1 3. 1 From the basic flow, the system displays an area for the user to enter Contact information. The 
fields that must be entered are: 

• Last Name 
And/or 

• First Name 

2.2. 1 3.2 The user enters a first and/or last name and accepts the new contact information entered. If 
the user chooses to exit the use case continues at System Displays Contacts in the basic flow. 

2.2.1 3.3 The system associates the new contact added to the Account chosen and the use case 
continues at User Selects to Exit the Vehicle/Shop Area in the basic flow. 0 

3, Special Requirements - Vehicle/Shop Use Case 

1 ) Year, Make and Model domain values come from the database. 

2) The list of years that the renter's vehicle was manufactured will be listed in descending 
order. 

3) The note entered into the Vehicle Notes field should be viewable from the Vehicle Notes 
section of the Vehicle/Shop screen. They WILL NOT be viewable from the Notes screen/use 
case.. 

4) A contact must be selected for every Account that is select as a Shop. 

5) The valid Account Types that are displayed to the user in Account Search are: 
o Body Shop 

o Corporate 
o Government 
o Fleet 
o Dealership 
o Insurance 
o Other 

6) The Branch Short List is currently being generated from the existing Legacy system and 
is being stored in a table on the Oracle database. 

7) The system should not search or display for any deactivated or deleted accounts. 

8) The user must have the ability to cancel a search at any time during the search. 

9) The Navigation Bar for the Vehicle/Shop area should display the following: 

a. Line 1 : Year, Make and Model of Renter's Vehicle 

b. Line 2: Shop Account Name 

10) Notes should be generated when any of the following events occur: 
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The user adds a 
"Not on File" 
contact. 

Not on file contact "First Name Last 
Name" was added for Account 
"XXXXX" 

Create/Edit 

Create (if data exists from 
the reservation) /Edit 

Vehicle/Shop 

The user changes 
the shop account 

Shop "XXXX" was changed to 
"XXXX". 

Edit 

Create (if data exists from 
the reservation) /Edit 

Vehicle/Shop 

The user changes 
the type of loss. 

Type of loss "XXXX" was changed 
to "XXXX". 

Edit 

Create (if data exists from 
the reservation) /Edit 

Vehicle/Shop 
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The user changes 
the "Total Loss?". 

Total Loss "XXXX" was changed to 
"XXXX". 

Edit 

Create (if data exists from 
the reservation) /Edit 

Vehicle/Shop 

Thp u^pr nhannes 
the date of loss. 

Date of loss "XXXXXX" was 

uaiu wl IvwO A/vvvvA WOO 

changed to "XXXXXX". 

Edit 

Crpatp (\f data pytete from 
the reservation) /Edit 

Vehicie/Shop 

The user changes 

nifmh^r f\f fhpft 

tlUltlUd Ul LMCU 

waiver days. 

Theft waiver days "X" was changed 
to "X" 

Fdit 

L.UK 

Create (if data exists from 
the reservation) /Edit 

VphiHp/Shon 

V CI UUIC/ W I 1 <J 

The user changes 

thea rontor'c \/phif*lp 

Year. 

The renter's vehicle Year "XXXX", 
wa<5 rhanapri to Ypar "XXXX" 

woo vi tally cu i\j i col /v/v/v/\ . 

Fdit 

Edit 

Vphirlp/Shnn 

The user changes 
the renter's vehicle 
Make. 

The renter's vehicle Make "XXXX", 
was changed to Make "XXXX". 

Edit 

Edit 

Vehicle/Shop 

The user changes 
the renter's vehicle 

IVlUUcl. 

The renter's vehicle Model "XXXX" 
was changed to Model "XXXX". 

Edit 

Edit 

Vehicle/Shop 

The user changes 
th§|registration 
npiber of the 
rater's vehicle. (If 
thejphysical 
terminal location is 
inllurope.) 

The renter's vehicle registration 
number "XXXX" was changed to 
"XXXX". 

Edit 

Edit 

* 

Vehicle/Shop 

Thf user changes 
tHp class of the 
renter's vehicle. (If 
^physical 
t^tfifnlna! location is 
irrJIermany.) 

The renter's vehicle class "X" was 
changed to "X*. 

Edit 

Edit 

Vehicie/Shop 


4. Pre-Conditions 

• A user is authorized through a login process to create or edit a reservation or ticket. 

• The user has accessed a reservation or ticket, either in the process of editing or creating. 

5- Post-Conditions 


6. Questions 
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Business Use-Case Specification: Allocate 

Charges 

1. Allocate Charg es 

1.1 Brief Description 

The purpose of this use case is to explain what the system does to allocate charges among 
responsible parties for a given rental. The Allocate Charges Use Case includes information from 
the Calculate Total Charges Use Case and shows the flow of events that will occur when the 
Allocate Charges function is utilized in the Reservation. Open Ticket Callbacks and Close Ticket 
processes. 

2. Flow Of Events 
2.1 Basic Workflow 

2. 1. 1 The System Is Called 

This use case begins when the system is called to allocate charges to each responsible party for a 
given rental during the closing of a ticket. If there is no bill-to the renter is responsible for the 
total charges, see alternate flow Renter Responsible. If the allocate charges is called for a 
reservation, see alternate flow Reservation . If the allocate charges is called for an open ticket see 
alternate flow Open Ticket . If the allocate charges is called for a callback, see alternate flow 
Callback . If a ticket is close-pended see alternate flow Close-Pend . 

2. 12 Bill-To Authorization Information (possible Scenarios) 

In order to allocate charges successfully, the system must have access to specific information 
associated with each bill-to. The information below is intended to provide helpful definitions with 
regards to authorization information. Note: Authorization dates can change during the course of a 
rental 

Authorized Charges Start and End Dates 

These dates apply and may vary for the unit, products, additional fees, taxes and surcharges. For 
example, a bill-to may authorize payment for a rental vehicle on a Monday, but authorize protection 
two days later. On the same token, a bill-to may stop paying for protection while continuing to pay 
for the rental vehicle. 

Authorized Maximum Daily Amount 

Amount of authorization may vary. A bill-to does not necessarily authorize the same daily rate 
through the duration of the rental period. For example, a bill-to may initially authorize an 
intermediate sized car. A week into the rental the bill bill-to may authorize a mini-van. 

Authorized Maximum Billable Amount 

An amount that the bill-to sets as the maximum they will be billed. For example, the total amount of 
the rental may be $1000, but the maximum billable amount is $750. 

No Maximum Amount 

The bill-to has set no maximum. This will most likely occur in the case of a claimant . 

Authorized Car Class Amount 
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The amount the bill-to will pay for a car class. For example, if a bill-to has authorized an 
intermediate sized car and the renter chooses to upgrade to a full size car, the system allocates the 
amount for the intermediate sized car charges to the bill-to and the difference to the renter. 

Authorized Products and Amount 

The amount a bill-to will authorize to pay for products. For example, a bill-to may authorize 
payment for a baby seat, but not for ski racks. The system also looks at the dates associated with 
each authorized product. 

Authorized Protection and Amount 

The amount a bill-to will authorize for protection . The system also looks are the dates associated 
with the protection that has been authorized. 

Authorized Additional Fees and Amount 

The amount a bill-to will authorize for additional fees . The system also looks at the dates associated 
with the additional fee that has been authorized. 

Authorized Taxes and Surcharges 

The amount a bill-to will authorize for taxes and surcharges per line item. 
Authorized Percentage 

The amount (as a percent) authorized by a bill-to. For example, a bill-to may pay 80% of the total 
amount 

2. 13 Calculate Total Charges Use Case Called 

In order to successfully allocate charges, the system will include the calculate total charges use 
case. The calcula te total charges use case p reviously determined t he total amou nts for each unit 
on a ticket as well as any amounts for additional distance dri ven, fuel, pro ducts, additional fees. 

2. 1.4 Amount(s) To Be Allocated 

Uie^ysteBLa llocates th ejoM^JMEei^^liear imary bill-to. If the pr imary bill<oJsj^onsible 
for an amount th aLisies& thap the total the remaining char ges will be allocated to the responsible 
party or parties. The system will sho w the amount allocated per c harge item . If there is more 
than one bill-to see alternate flow multiple bill-to ? s . 

2.15 Vehicle Amount 

The authorized vehicle amount i s allocated to the prim ary bill-to. This amount may be a flat 
Mmntmam ount plus ta xes/surcharges, or a perc entage of an amount. If the bill-To is paving 
less than the total amount of the vehicle, see alternate flow Partial Vehicle Amount . If the bill-to 
is paying for the entire amount of the vehicle the use case continues to the next step. 

2.16 Distance Driven 

If the bill-to has not authorized to pay for additional distance driven go to alternate flow limited 
distance . If unlimited distance is assigned to the ticket, the main flow continues at the next step. 

2.17 Fuel 

If the bill-to has not authorized to pay for any fuel charges go to alternate flow Fuel Charge . If 
there are no charges for fuel, the main flow continues at the next step. 
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218 Additional Products 

If the bill-to has not authorized to pay for any additional products go to alternate flow Additional 
Product Charge . If there are no charges for additional products, the main flow continues at the 
next step. 

2.19 Additional Fees 

If the bill-to has not authorized to pay for any additional fees go to alternate flow Additional Fees 
Charge . If there are no charges for additional fees, the main flow continues at the next step. 

2.1.10 Protection Charges 

If the bill-to has not authorized to pay for any protection go to alternate flow Protection Charges . 
If there are no charges for protection, the main flow continues at the next step. 

2.1.11 Taxes/Surcharges 

If the bill-to has not authorized to pay for any taxes/surcharges go to alternate flow 
Taxes/Surcharges Charges . If there are no taxes/surcharges applied, the main flow continues at 
the next step. 

2.1.12 Miscellaneous Fees 

If the bill-to has not authorized to pay for any miscellaneous fees go to alternate flow 
Miscellaneous Fees Charges. If there are no miscellaneous fees applied, the main flow continues 
at the next step. 

2.1.13 The use case ends. 

The total amount has been allocated to the primary bill-to. 

2.2 Alternative Workflows 

2.2.1 Multiple Bill-To's 

Iffliere are multiple bill-to's the system looks_a t each non- primarvbill-to and allocates the a mount 
mciLbjlJztoj s responsibl e for (beginning with the seconda ry bill-to. followed by the tertiar\^etc^ . 
The use case continues at Vehicle Amount in the main flow. For more information, see 
Mathematical Formulas Primary. Secondary, and Renter Mathematical Fonnula and Primary and 
Secondary Bill-To Mathematical Formula . 

2. 2. 2 Renter Responsible 

If no author izations e xist the system allocat es the tota l amount to the renter . 

2.2.3 Partial Vehicle Amount 

The system a llocates a nv amount of the vehicle, not authorized by the primary b ill-to. to the 
responsible party . For additional information see Mathematical Formula Primary Bill-To. Renter 
Mathematical Formula . 

2.2.4 Limited Distance 

The system allocates anv amoimt for additional distance driven, not authorized by the primary bill- 
to, to the responsible party . 

2.2.5 Fuel Charge 

The system allocates any amount for fuel charges, not authorized bv the primary bill-t 
responsible party- . 
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2.2.6 Additional P roduct Charge 

The svstem al locates anv amount for additional products, no t authorized bv the primary bill-to. to 
the responsible party . 

2.2.7 Additional Fees Charge 

The svstem allocates anv amount for additional fees, not authorized bv the primary bill-to. to the 
responsible partv , 

2.2.8 Protection Charges 

The svstem allocates anv amount for protection charges, not authorized bv the primary bill-to. to 
the responsible partv . 

2.2.9 Taxes/Surcharges Charges 

The svstem alto^e^^ivariiount fo r anv taxe s/surcharges, not authorized bv the primary bijktojg 
the remon^ble_party For more information see Taxes/Surcharges Mathematical Formula . 

2.2.10 Miscellane ous Fees Charges 

The svstem allocates anv amount for miscellaneous fees, not authorized bv th e primary bill-to, to 
the responsible nartv . 

2.2.11 Reservation 

There are certain variables that will not be known at the time of a reservation that may or may not 
be relevant to allocating charges. For example, at the time the reservation is taken, actual distance 
driven will not be known. If limited distance is given to the renter, and distance the renter drives 
goes over what is allowed, someone will have to be responsible for that amount and it will be 
allocated to either the renter or a bill-to. When closing the ticket, this amount will be allocated to 
the correct party. 

2.2.12 Callback 

In the case of a callback the system allocates charges based on the information available. 
However, until the ticket is actually closed, the exact amount(s) to be allocated will not be known. 

2.2.13 Open Ticket 

When a ticket is opened the system can allocate charges based on the information given at that 
time. However, until the ticket is actually closed, certain information (i.e. distance driven, fuel, 
protection, etc.) may change affecting the allocation. 

2.2.14 Close-Pend 

In the case of a close-pend, the system does not have access to all the Authorization Information as 
documented above and the ticket cannot be closed completely and charges cannot be allocated 
until the information is received (for example, ending miles or an extension from a bill-to on an 
authorization). 

2.2.15 The use case ends. 

The system has allocated charges to each responsible party. 

3. Special Requirements 
3.1 <First special requirements 

4. Pre-Conditions 

It is expected that information received will have been already validated since no 
validation will be taking place in the allocation engine. 
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A user must initiate an event tri ggerin g a process requiring allocating charges to be 
displayed. This event mav be calling a n allocating charges panel or a payment 
panel . 

5. Post Conditions 

5.1 <Post-condition One> 

6. Extension Points 

6.1 <name of extension point> 

7. Questions 

8. Mathematical Formulas 

8.1 Primary. Sec ondary, and Renter Mathematical Formula 

A renter is in a standard size vehicle for 5 days (calendar billing cycled at a rate of S3Q.00 per dav. 
The primary bill-To will onlv pa y S25 a day f lat towards a vehicle. The secondary bil l-To agrees 
to pick up the difference in the co$t ofj he vehicle, which is S5.00 a day. In addition there is a tax 
of 5% ap plicab le to the entir e rental which is the renter's responsibility. The bill-to' s will pay for 
the rate only* excluding the 5% tax . 


Authorized^: 

Monday 

Tuesday 

Wednesday 

Thursday 

Friday 

Primary bill-To (bill-To 1) 
Amount Authorized Per Day 
$125=$25X5days 

$25 

$25 

$25 

$25 

$25 

Secondary bill-To (bill-To 2) 
Amount Authorized Per Day 
$25=$5X5days 

$5 

$5 

$5 

$5 

$5 

Renter 

Responsibility Per Day 
$7.50=$1 .50X5 days 

$1.50 

$1.50 

$1.50 

$1.50 

$150 


8.2 Primary and Secondary Bill-To Mathematical Formula 

A renter is in a vehicle for s ix davs using a 24-hour billing cycl e. The rate is $25.00 a dav plus 
taxes at 7.25%. The primary bill- To is auth orizing to p av $25.00 a dav plus the 725% for the first 
four davs. The secondary b ill-To is au thorizing to pay $25.00 a day plus the 7.25% for the next 
two davs . 


Authorized By: 

Monday 

Tuesday 

Wednesday | Thursday 

Friday 

Saturday 

Primary bill-To (bill-To 1) 
Amount Authorized Per Day 
$107.25=($25 X 4 days) X 
(7.25%) 

$25 + 
7.25% 

$25 + 
7.25% 

$25 + 7.25% 

$25 + 
7.25% 



Secondary bill-To (bill-To 2) 
Amount Authorized Per Day 
$53.625=($25X2days)X 
(7.25%) 





$25 + 
7.25% 

$25 + 
7.25% | 

Renter 

Responsibility Per Day 
Zero Amount Allocated to 
Renter 

0 

0 

0 

0 

0 

0 
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8.3 Primary BiH- To r Renter Mathematical Formula 

The primary bill-to authori zesJ21,99,a dav for a standard sized vehicle pins 5% tax on that 
ammint^Jiowey er. the rente iichoosesjo, u pgi'ade into a full-size vehicle of $28 .99 a day and is 
EggponsMefor the difference 

$28.99 X 5 days X .05=1 52.20 


Primary biii-to . $25.99 x 5 days x .os%«136.4s 
Renter; $3 x 5x .05=15,75 


8.4 Taxes/Surcharges Mathe matical Formula 

In this example, the primary bill-to has authorized to pav $23.99 a dav plus a 5% sales tax for a 
duration of 5 davs. However, there is also a 10% stadium tax that tteMdoMUjStJBiXto^ 
the renter is resp oasibteJaL 

Bill-To; S ttS.M=TC23.09 X S rlav^ X f*%WS125.<)S 


JBenten. S137.94-S125.<>5=S.1 ,IM 
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Charges 

1. Calculate T otal Charges 

1.1 Brief Description 

The purpose of this use case is to explain what the system does to determine total charges for a given rental 
transaction . The calculate total charges function can be utilized during the reservation, open ticket close 
ticket and/or callback process. The system determines and presents total charges used to quote a renter or 
account and may be used for payment or deposit information. 

2. Flow of Events 
2.1 Basic Workflow 

2.1.1 Use Case Begins 

The use case begins when a rental application calls the system (ECARS, NatRes, ARMS, 
www.enterprise.com) to calculate total charges at the close of a ticket. If the calculate total charges 
function is called for a reservation, see alternate flow Reservation . If the calculate total charges function is 
called for an open ticket, see alternate flow Open Ticket. If the calculate total charges is called for a 
callback, see alternate flow Callback . If a ticket is close-pended. see alternate flow Close-Pend . 
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2.12 Grou pings A-G 

Grouping A c ontains the m inimum v ehicle inform ation that is re quired to determine total charges upon 
closing a ticket . Ctougjn£_A l contain s information pertaining to the rental unit thatjnay_orm av not affect 
total. For ex ample, a r enter mav have been given limite d distance but exceeds the give n limit In this case, 
an amount will apply fo r the additional distance driven. However, if in the same s cenario, th e renter was 
given unlimi ted driving distance, there would b e no amou nt affectinglhe total charges . 

Groupings B-G c ontain other criteria that mav or mav not be used when determining the total charges . 
GroupingA- l Jni£ Information (required) 

• Group Branch 

• Start charges date fa renter could pick up a car on a Monday but for some reason the charges for 
the vehicle may not begin until the following dav) 

• End charges date 

• Anv rate changes associated with the unit (i.e.. if the renter switched into a different car class 
resulting in a rate change, a weekend special 

• Charge Frequency 

• Billin g cvcle (24 hour or calendar dav) 
ffi^y£lM^mi^M^£ !^i^ the weeklv and ™>nthlv rates are not required) 
Grouping A 1 -Unit Information (fact ors that ma\ o r mav not effect total charges) 

• Be ginning odometer reading 

• Ending odo meter reading 

• Total dista nce driven (the system determines the total distance driven a nd whether or not limited 
grjmlimited distance is applicable additional distance cha rgesmav or mav not apply) 

• Additional distance charge (if a limited distance if applicable anv additional distance driven will 
result in a additional charge total) 

• Beginning fuel level 

• Ending fuel level 

GEfflffliag B-P rodnct Information 

» End charges date 

• Djjratjon.ofp roduct 

• M)v rate of product 

• Weekly rate of product 

• Monthly rate of product 

• Rate of produ ct per rental 


Grouping C-DisCOUntS 

• Start date of discount 


• Duration of discount 

* Is discount off daily rate 



off monthly rate 


is discount off entire rental 

Is there more than one discount 

Is it an emplovee/emplovee's family discount? 
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Theft waive r (note: theft waiver will not a pply on a retail ticket situation- se e alternate flow Theft 
Waiver 


• Start date of fee 

• End date of fee 


• Is fee charged daily 

• Is fee charged weekly 

is fee per rental 

• Is there more than one fee 
Groupjn^ErPr^e^ion 

• Start date of protection 

• End date of protection 

• Duration of protection 

• What tvpef s) of protection (( 
Grouping F- Applicable Taxes and Surcharges 

• Start date of tax and/or surcharge 

• End date of tax and/or surcharge 

• is there more than one tax and/or surcharge 
Grouping G -Miscellaneous Fees and Refunds 

• Amount of fee or refund per rental 

• Drogfee 
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2.13 


Unit Information (from Grouping A) 

IrLdetermiaiflg the cbarg^a^a^d^tMbejmiLat the closing of a ticket, the system looks at the 
following information: 

* the date a unit was rented and the date a unit was returned (The system does this for everv unit 
found on a rental ticket as there may be multiple units assigned to one ticket) 

• whether or not the date a unit went out is equal to the date the charges f or that unit started. If the 
start charges date is different than the date the unit went out, see alternat e flow Start Charges if 
Different Date. 


the billing cycle associated with the open ticket a nd whether a 24-hour or a calendar dax^ydejs 


2. 14 Multiple Rates 

If a ticket cont ains more than one set of rates (due to a unit swit ch either requested bv the renter or the 
renting branch, a weekend special change in rate source, or anv other reason! th e system looks at all the 
rates. The system will calculate the total charges based on the number of days associated wi 


each rate (there mav be just one rate, but there may be multiples! . 

2.15 Calendar Dav Cvcle 

If a calendar day billing cycle has been selected, the system returns a daily rate . If a 24 hour billing cycle 
has been selected see alternate flow 24 hour Billing Cycle . The system will look atlhe^^iljcharg^dale 
and end charges date and this total number of days will hejnufr^^ 

a particular rate applies and determine the total charges for each rate 

2. 1 6 Fuel Information 

The system finds no charges for fuel and the use case continues at the next step. If fuel charges apply, see 
alternate flow Fuel 

2. 1 7 Distance Information 

The system finds no charges for additional distance driven. If additional distance charges apply, see 
alternate flow Distance . 

2. 18 Product Information 

The system finds no products and the use case continues at the next step. If products apply see alternate 
flow Products . 

2. 1 9 Discounts Information 

The system finds no applicable discounts and the use case continues at the next step. If discounts apply see 
alternate flow Discounts . 

2.1.10 Additional Fee Information 

The system finds no additional fees and the use case continues at the next step. If additional fees apply see 
alternate flow Additional Fees . 

2.1.11 Protection Information 

The system finds no charges for protection and the use case continues at the next step. If charges for 
protection apply, see alternate flow Protection . 

2.1.12 Miscellaneous Fees/Refunds Information 

The system finds no applicable miscellaneous fees and/or refunds. If any fees and/or refunds apply, see 
alternate flow Miscellaneous Fees/Refunds . 
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2. 1. 13 Special Rate Information 

The system finds no special rates. If special rates apply see alternate flow Special Rates . 

2.1.14 Tax Rules Processing 

The Tax Rul es System goes through each of the above charge s and applies any applicable taxes and/or 
surcharges. The system determines w hich line item s are taxable and which are not. Different taxes may 
ag p1v to differgntjtgms. The system a lso determines if an account is tax exempt. The Tax RulesSystem 
will specify the char ge amou nt forGgygrnment Surcharge, Airport A cce ss, and an y other taxes.JDi^ g 
charges with in the Tax Rules System are s pecified either in per day, per rental, or percentage amounts . 

2.1.15 The use case ends. 

An amount reflecting the total charges is returned. 

2.2 Alternative Workflows 

2.2.1 Distance 

The system determines total distance driven. The system subtracts the beginning distance from the ending 
distance to determine tot al dist ance driven. For each unit on the tic k et the system will determin e the 
distance dri vem Based on the distance driven and whether or not a ranter was given limited or unlimited 

2.2.2 EM 

The system determines fuel charges. The svstem will determine a total amount based on a per gallon 
charge, quarter tank charge, an empty tank charge, prepaid etc . (see mathematical formulas Fuel for more 
information) 

2.2.3 Products 

The system determines the total amount t hatis. duejpxa nv products. The system looks at the start charge 
and end dates for each product. For each product the svstem will look at the number of davs associated 
with it and multiply the rate times tii ejumnberjqf davs (note: i.e.. if the billjn^c ycle is 24-hoiiLaadJte 
renter has a vehicle for two extra hours an d is charged SI 5 an hour for the vehicle, that hourly charge does 
not extend to t hg_product ). 

2.2.4 Discounts 

The system applies anv discounts. It must be determined what type of discount should be applied. The 
system looks at whether the discount is a flat fee or a percentage. The following are the possible discount 


• A rate discount 

• A rate and mile a^ejjis^ount 

• A total charges discount 


The system will look at whether or not the discounts applied are per dav. per week, per month, or per 
rental. For each discoun t found, the svstem proc esses the tot al discount to be applied . It is a business 
requiremen t that the discount cannot exceed m ore than 50% of the total charges . See mathematical 
formulas Discount for more information 

2.2.5 Additional Fees 

The svstem determines the ad di tional fees. The svstem looks at the start and end dates for each additional 
fee and determines the total amount to be charged per fee. This may be a dailv. weekly, monthly, or per 
rental fee . 
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2.2.6 Protection 

The system determines the amount due for protection. The system looks at the start and end dates 
type of protection and determines the total amount. Based on the letigfo of the rental the system 
determines what the appropriate rate to charge is. For example, in New York. Personal Accident Insurance 
k steered so the first dav charge mav be different than the charges for subsequent days . 

2.2.7 Applicable Taxes and Surcharges 

The system determines the amount for applica ble faxes and surcharges. The system looks at the start and 
end dates for each tvpe of applicable tax and/or surcharge and determines the total amount . 

2.2.8 Miscellane ous Fees and Refunds 

The system determines the a mount for app licable miscellaneous fees and/or refunds. The svstem looks at 
each fee/refund and determines the total amount . 

2.2.9 Special Rates 

The svstem determines that a special rate applies and determines the .total amount . 

2.2.10 Start Charges if Different Date 

The system determines the charges associated with a rental unit based on the start charges date. For 
sample, a renter may rent a unit on a Monday but charges for that unit begin the following dav and the 
svstem will determine this . Go back to main flow unit information (required). 

2.2.11 74 Hour Billing Cycle 

If a ?4 hour billing cvcle is in place, the svstem will look at the number of davs a n d h ou r s (if applicable) 
Undated with each rate and determine ttV test rate possible bv lookin g at the charge frequency . See 
Mathematical Formulas Determining Amount for examples. 

2.2.12 Reservation 

The system can calculate the total charges during the taking of a reservation. Unlike closing a ticket, the 
exact total may not be known (i.e. at the close of the ticket there may be charges for fuel, distance, etc.) 

2.2.13 Open Ticket 

The system can calculate total charges when opening a ticket. Unlike closing a ticket, the exact total may 
not be known (i.e. at the close of the ticket there may be charges for fuel, distance, etc). 

2.2.14 Callback 

The system can calculate the total charges in a callback. Unlike closing a ticket, the exact total may not be 
known (i.e. at the close of the ticket there may be charges for fuel, distance, etc.) 

2.2.15 Ctose-Pended 

The system can calculate total charges if a ticket is close-pended. However, some information is most 
likely missing that may effect the total charges so the exact total is not known until the close of the ticket. 

2.2.16 The Use Case Ends 

An amount is returned which reflects the total charges for the ticket. 

3. Special Requirements 

3.1 <First Special Requirement 

4. Pra-Conditions 

• A user must initiate an event tripling a process requiring the calculated charges to he displayed 


Confidential 


©Enterprise Rent-A-Car, 2000 


Page 10 


Enterprise Rent-A-Car 


Open Ticket Use Case: 

Get Rates 

Version 1.1 



Version: <1.0> 

Open Ticket Use Case: 

Date: <dd/mmm/yy> 

<document identified 


Revision History 


Date 

Version 

Description 

Author 

08/31/2001 

1.0 

First draft of Get Rates flow using Perot Engine(s) 

Johnny S. Johnston 

09/13/2001 

1.1 

Changes from business review 

Johnny S. Johnston 






















Confidential 


©Enterprise Rent-A-Car, 2000 


Page 2 



Version: <1.0> 

Open Ticket Use Case: 

Date: <dd/nimm/yy> 

<document identified 

Table of Contents 



1 . Open Ticket Get Rates 


4 

1 . 1 Brief Description 


4 

2 Flow of F verify 


A 

<*> 1 * T">1 

2. 1 Basic Flow 


4 

2.1.1 Use Case Begins 


4 

2. 1 .2 Information Needed For Rate Retrieval 


4 

2. 1 .3 Pickup Group and Branch 


5 

2.1.4 Pickup date and time 


5 

2. 1 .5 Keturn Oroup ana Branch 


5 

2. 1 .6 Return Date and Time 


5 

2 . 1 .7 Booking Channel - Reservation Origin 


5 

2.1.5 Rental Status 


c 

5 

2.1,9 Rate Source 


5 

2.L10 Rental Type 


5 

2.1.11 Billing Cycle 


5 

z. nz unit v emcie ) oeiecuon 


0 

2.L13 Get Rates 


6 

2.1.14 System Returns itates 


6 



6 

2. 1. 16 Car Class Not Present In Account Rate Plan 


6 

3. Special Requirements 


8 

3 . 1 GDS Response Time 


8 

4. Pre-Conditions 


8 

4. 1 User must be logged on 


8 

5. Post-Conditions 


8 

5.1 < Post-condition One > 


8 

6. Extension Points 


8 

6. 1 <Name of Extension Point> 


8 

7. Questions 


8 


Confidential 


©Enterprise Rent-A-Car, 2000 


Page 3 



Version: <1.0> 

Open Ticket Use Case: 

Date: <dd/mmm/yy> 

<document identified 


Business Use-Case: Open Ticket Get Rates using Perot Engine(s) 

1. Open Ticket Get Rates 

1.1 Brief Description 

The purpose of this use case is to attempt to describe what information must be fed from the 
ECARS 2.0 system to the Perot Enoine(s) in order to retrieve the appropriate rates for each 
product for the r ental transa ction. In this use case the products fo r which a rate is to be retrieved 
are the vehicle and ail ap plicable coverages, where offered ( CPW. PAl and SLPY The ECARS 
2.0 system will provide the Perot system with specific information about the transaction in order to 
successfully retrieve rates. This use case is specifically a ddressing a walk in. open ticket, rental 
transaction. 

2. Flow of Events 

2.1 Basic Flow 

2.1.1 Use Case Begins 

This use case should be able to be invoke d from anywh ere in the O pen Ticket pr ocess and 
initiate the reque st for rates, for appropriate products (in this case vehic le and coverages), from 
the, Perot Enoine(s) for a specific rental transaction. (Eventually, this use case will evolve into the 
one, which is used to get rates for all functions. Reservation. Open and Pre-Write) 

2.1.2 Information Needed For Rate Retrieval 

The ECARS 2.0 system will need to provide specific information from the transaction to the Perot 
system to retrieve rates. Perot will require specific information before it will be able to search for 
products and their associated rates. Below is the list of items the Perot system will need to 
retrieve rates for an open ticket: (Note: Perot has six engines it uses to get rates for various 
products. The Rate engine for Vehicle, the Charge engine for estimating and allocating charges, 
the Equipment engine for ancillary items such as child seat and ski rack, the Coverage engine for 
insurance coverages, the Ancillary engine for add on fees such as youthful driver and additional 
driver and the General conditions engine for providing messages and standard conditions.) 


« The pickup cr oup and branch 

• The pickup date 

• The pickup time 

• The return group and branch 

• The return date 

• The return time 

• The booking channel (reservation origin) 

• The rental status (ticket status - reserv ation, open, closed...) 

• The rate so urce (account number, account nam e or default type) 

• The rental type (insurance, body shoo, dealership, etc.) 

• The billing cycle 

Note: There needs to be some wav tha t the user has the ability specify a start charges date 
and time that is different than the pick-up date and time. 
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Having values for all of the above items will a llow the system to re trieve either a single rate plan 
or display all multiple rat e plans to the user, so the v can choo se which one to use. Once a single 
rate plan has been selected, entering or selecting the followin g information will allow the system 
to show a rate by product. 


• The specific unit (vehicle), either a direct entry or selection from a list ing of available 
units. ^ ~ ^ 

• The option to display the car classes a ssociated with the rate plan. 

• The coverage s fas related to car class) 


2.1.3 Pickup Group and Branch 

. By the time this use case is invoked, the system should have already defaulted the pickup group 
and branch to the terminal location group and branch 

2.1.4 Pickup date and time 

jfthe user has not entered a p ickup da te and time, then the system will def ault the date and time 
tocurrent. The user can then have the abi lity to change it. 

2.1.5 Return Gro up and Branch 

Ihe system should default the return group and branch to the same as the pic kup group and 
branch and allow the user to edit or chance this. 

2.1 .6 Return Da te and Time 

The user is reouired to entered a return date and time. 

2.1.7 Booking Channel - Reservation Origin 

The reservation origin should be able to be distinguished bv the system and have the appropriate 
value assigned bv the system. 

2.1.8 Rental Status 

For this us e case the status will be "Open". The system should be able to det ermine the status 
and assign the appro priate value for ail instances of a r ental transaction. 

2.1.9 Rate Source 

The user has either selected an account name or account number to locate and assign a rate 
source, or has selected to use the default rates. 

2.1.10 Rental Tvoe 

The user is required to select a rental type. 

2.1.11 Billing Cvcle 

The user is reguired to select a billing cycle. 


With the above information entered into the system, selected by the user, or determined by the 
system, the Perot engine should be able to return any and all associated rate plans with a 
particular account. 

If there are multiple rate plans (agreements! the system should display this information 
to the user, and provide a way to select the appropriate one. Use case continue s below. 
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If there is a single rate p lan ( agreement! the area is populated with that p lan textual 
description. 


2.1.12 Unit (Vehicle) Selection 

The system will allow the user to either enter a specific unit number or to have the ability to select 
one from a list of available units. 

2.1.13 Display all Car Classes for Rate Plan option. 

The system wil l have a feature available which wil l allow the user to displa y all of the car 
daises associat ed with th e specific rate plan selected and the corresponding rates for each 


Once the user has selected a single car class the system will display the units available for 
that car class. When the user selects a vehicle fUnifL this u se case continues below. 

2.114 Get Rates 

Once a specific unit has been identified or selected bv the user, there should be some 
mechanism to allow the user to specify to the system to aet the rates. 

2.1.15 System Re turns Rates 

With all of the p reviously entered or system derived in formation, the system d etermines bv the 
specific unit, the rate and car class and returns the rate for the vehicle and the appropriate rate 
forall applicable coverages COW. PAI and SLP. 

The rate information is presen ted to the user bv product for daily. weekly T monthly and hourly time 
periods, if a rate is not available for a time period, the sys tem returns a value of zero. 

This informatio n is displ ayed to the user in a manner that allows editing or chang ing of the rates. 
Anv changes in the rates will only apply to th is specific ren tal transactio n, and will not be reflected 
back in the rate pMrv 

If the system cannot find a car class, based on the unit, for that rate plan, the use case continues 
atCar Class Not Present In Account Rate Plan. 

2.1.16 User Accepts Rates Returned. 

The system ret urns the rates for the time periods indicated f or the vehicle, selected or indicated, 
and all availa ble coverag es. CDW. PAI and SLP. Th e user accepts the rate without changes, 
informs the renter of the rates by product, and saves the transaction. 

The user also has an option to have the system to calculate t otal char ges, for the selected 
products, over the duration of the rental. This will invoke the estimated charges use case. 


The use case ends. 

2.1.17 Car Class Not Present In Account Rate Plan 

If the car class is not present in the acco unt rate plan, the system notifies the user of this and 
gives the user the option of using default rates, selecting a different car class within the specific 
rate plan, selecting another ra te source or manually entering in the rates for the vehicle and/or 
coverages. 

If another rate source is selected, default or another account the use case resumes at 2.1.9. 
If another car class is selected within the specific rate plan, the use case re sumes at 2.1.13. 
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If the user manuall y elects to manu ally enter the rates, the re should be some functi on to allow 
this process. The rates will be saved with the rental transaction. 


This use case ends. 
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3. Special Requirements 

3.1 If anv component of the information need ed for rate retrieval is changed which cau ses a change 
in the rates for anv item, a message is di splayed to the user informing them of such. 

3.2 GPS Response Time 

Our contracts with GPS systems reouire that a response be returned to a rate reouest within 
seven seconds. 

4. Pre-Conditions 

4.1 User must be logged on 

• The user is l ogged into ECARS 2.0 2.0 application and ECARS 2.0 has validated the 
user has privileges to perform rate verification. 

• The user has access to the local machine,. 

• The user ha s access to the network. 

5. Post-Conditions 
5.1 < Post-condition One > 

6. Extension Points 

6.1 <Name of Extension Point> 

7. Questions - all answered in initial business review. 
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1. Rate Verification 

1.1 Brief Description 

The purpose of this use case is to give the user (an employee that will perform data entry) the 
ability to verify that rate information was correctly entered into the system. The system invokes 
the retrieve rates use case allowing the user to verify the rates were correctly entered. 

2. Flow of Events 
2.1 Basic Workflow 

2.1.1 Use case begins 

This use case begins when the system presents an authorized user (most likely an administrative 
employee) input fields to enter specific criteria . {Note: the user entering the rates may or may not be the same 
individual verifying them when they are returned). 

2.1.2 Fields Displayed for Rate Verification 

Upon entry, the user will see fields displayed. The required fields are pickup group branch, pick- 
up date, and pickup time. If these fields are left blank no validation will occur. 

• Pickup group branch (required) 

• Pickup date (required) 

• Pickup time (required) 

• Return date (this will default to the next day if the user does not enter anything) 

• Return time (this will default to the next day if the user does not enter anything) 

• Billing cycle 

• Booking channel (required) 

• Car class and 

• Rate Source (this may be an account number or a standard type) 

• Products/Coverages 

• Fuel Charges 

• Excess Distance Driven 

• Airport Fees 

2.1.3 Initiating Call 

The user enters criteria and the rental system initiates the call to the retrieve rates use case. 

2.1.4 System Validates Entered Criteria 

The system validates there is enough criteria entered to continue and the retrieve rates use case 
is invoked. If not enough criteria was entered see alternate flow Invalid Criteria. 

2. 1.5 Retrieve Rates Use Case 

The retrieve rates use case is made available and if a valid rate structure is present the use case 
continues at the next step. If the rate retrieval was unsuccessful, see alternate flow Unsuccessful 
Rate Retrieval. 
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Z1.6 Display Output Fields 

The rates system displays out put fields con taining information based on the input entered bv the 

• Agreement number 

• Agreement name 

• Contractual condition ID 

• Contractual condition Name 

• Product name 

• Product ID 

• Rate header name 

• Rate detail 

Note: If there are multiple billing types the user can select one and another call to the 
rates system is performed. 

2.1.7 Verify Correct Rates Returned 

The rates sy stem return s rates based on the info rmation prov ided bv the rental system. The user goes 
through a manual proces s of looking at the rates returned and verifies the rates are valid . if they are 
valid, the user can continue on at the main flow Initiating Call . If the system does not return the expected 
rates see alternate flow Incorrect Rates . 

2. 1. 8 The use case ends. 

2.2 Alternative Workflow 

2.2.1 Invalid Criteria 

When the system is validatin g the entered information, it will not return anv rates if not enough 
information is ent ered. The user can return to main flow and re-enter criteria to once aoain 
search for rates or the use case ends . 

2. 2.2 Unsuccessful Rate Retrieval 

UC5.2 2.2 Based on the criteria entered, the system returns no rates. The user can return to the 
main flow and re-enter criteria to once aaain search for rates or the use case ends . 

2. 2. 3 Incorrect Rates 

The system returns incorrect rates. The user can select which rate is incorrect and immediately 
go into audit mode and view the incorrect rate (TBD). 

2.2.4 The use case ends. 

3 Special Requirements 

4 Preconditions 

• The user is logged into E CARS 2.0 application and E HARS has validated the user has 
privile ges to p erform rat e verification. 

• The user ha s access to the local machine. 

• The user has access to the network. 
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5 Post Conditions 

2.3 5.1 <Post-condition One> 

6 Extension Points 

2.4 6.1 <name of extension point> 

7 Questions 

2.5 7.1 Security Access 

Can the user entering and verifying rates change the group or region for rate 
verification? What type of access should they have? 

2.6 7.2 Change Incorrect Rates 

When a user is viewing the incorrect rate shouid they have access there to go into 
another mode to change it right away or be able to put some sort of comment in 
regarding which rate was incorrect, etc? 
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surcharges that are brought back 

Allison Bruhn 
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Business Use-Case Specification: Rates Window 


1. Rates Window 

1.1 Brief Description 

This use case will describe how a user interacts with the system to receive a rate or rates (within 
reservation, open, and close of a ticket) based on specific criteria entered. Examples of information that 
may be entered consists of group and branch, pick-up dates and times, car class, billing cycle, etc. It is 
envisioned that this process will take place through some sort of a rates window where input fields exist for 
the user to enter the different criteria and in return rates will be returned via some sort of window 
containing output fields. The user should then have the ability to calculate total charges once the rate or 
rates are received as well as add/remove criteria and recalculate the total. The user will also be able to 
receive the taxes and surcharges that are applicable to certain items. 

2. Flow of Events 

2.1 Basic Workflow 

2. 1 . 1 Use Case Begins 

The use case begins when a user chooses to work with the rates window function. 

2. 12 Display Rates Window 

The system displ ays all in put criteria fields within the rates w indow where the user can enter information 
(please refer to the Supplementary Action Specification for exact detail) . The following fields are 
displayed upon entry to the rates window: 

• Status of the ticket (reservation, open, or close) 

• Pickup Group (mandatory-defaults to the current group) 

• Pickup Branch (mandatory-the user can select which branch they wish to work with) 

• Return Group 

• Return Branch 

• Pickup Date (mandatory) 

• Return Date 

• Pickup Time 

• Return Time 

• Rate Source (mandatory-default to retail) 

• Account Number 

• Billing Cycle (optional on res, mandatory on open and close ticket) 

• Car Class 

• Fuel 

• Distance 

• Specific Unit Number (mandatory open and close of ticket) 

• Booking Channel (default to branch-mandatory) 
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• Rate Type (Insurance, Body Shop, Dealership, Corporate, Government, Fleet, Retail) 

• Rental Type 

2. 1.3 Criteria Entered 

The user en ters grou p branch, pickup and re turn dates and times, car class, rate source or any other 
combination of the criteria . If the group branch is a VLF Group see alternate flow VLF Ranges . 

2.1 A Information Sent 

The system sends information to the rate retrieval system. The system confirms the information is valid. If 
the information entered is not valid, see alternate flow Invalid Information Entered . 

2.15 Rate Sent Back 

Based on t he information entered a rate or rates are returned . If the system finds no rate based on the 
criteria entered see alternate flow No Rates Found . If the system returns multiple rates, see alternate flow 
Multiple Rates Returned . 

2.1.6 Calculate Total Charges 

Once the user has received a ratefs) back from the system after inputting certain input fields, thev have the 
option to calculate the total charges. The user wi ll be able to see anv applicable taxes associated with the 
transaction . 

2. 1. 7 The Use Case Ends 
2-2 Alternative Workflows 

2. 2. 1 invalid Information Entered 

The user has incorrec tly entered one or more of the cri teria (i.e. invalid pickup date, return date. etcX 
Some type of error message should be presented to the u ser indicating; the information entered is invalid . 
The user can choose to re-enter the information and the use case continues at the main flow Criteria 
Entered . If they choose not to re-enter, the use case ends. The user can also choose to cancel and any time. 

2. 2. 2 No Rates Found 

The system finds no rates based on the criteria entered by the user. The user can choose to re-enter the 
criteria and the use case continues at the main flow Criteria Entered or the user can choose to cancel and 
the use case ends. 

2. 2. 3 Multiple Rates Returned 

Based on the criteria entered, the system returns more than one rate. The user can choose to select one rate 
or choose to enter more criteria to narrow the list of rates down and the use case continues at the main flow 
Criteria Entered . 

2.2.4 Invalid Account Entered 

The account number entered is not vali d. Some message should b e produced t o the user alerting them of 
this (^invalid account number *V The system should check the validity of the account n umber prior to the 
information being sent to the engine . The user can return to the main flow and re-enter criteria once again 
to search for rates or the use case ends. 

2.2.4.1 Valid Account Entered Containing No Rates 

The account number en tered by the user is valid, however, no rate structure is set up for that account. 
Based on the rate type a ssociated with the accoun t number, default rates are returned . 

2.2.5 VLF Ranges 
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Ifjhejisgnc hooses to receive VLF ranges for a reservation a car class must be ent ered. For the open and 
close of a ticket, the s pecific unit must be on the ticket to receive th e specific VLF rate. The VLF ratejs 
returned when the user chooses to calculate total charges as this engine calls the taxes engine in which VLF 


2 2. 6 Special Equipment 

The user chooses to add or r emove one or more items t hat fall under special equipment (see Definitions 
section at the end) . If the user initiates this process the coverages engine will be called. The use case 
continues at the main flow Information Sent . 

2.2.7 Coverages 

The user chooses to add or remove a coverage . If the user initiates this process the coverages engine will 
be called. The use case continues at the main flow Information Sent . 

2. 2. 8 Ancillary Charges 

The user cho oses to add or remove one or more ancillary- items . If the user initiates this process the 
coverages engines will be called. The user case continues at the main flow Information Sent 

2. 2. 9 The Use Case Ends 

3. Special Requirements 

4. Pre-Conditions 

The user has access to the local machine 

The user is logged into the ECARS 2.0 application and the user has been granted access to the 
rates window 

5. Post Conditions 

5.1 < Post-condition One> 

6. Extension Points 
6.1 <name of extension point> 

7. Definitions 

• Coverage (CDW,PAI, PEC &SLP) 

• Ancillary Charges (Additional Driver & Young Renter) 

• Special Equipment(Child Seats, Tire Chains, Bike Rack, etc..) 

8. European Requirements 
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Allison Bruhn 

05/22/2001 

1.6 

Changes based on user review; took out alternate 
flow UM location; in addition to the fields marked 
required in Information Needed for Rate Retrieval, 
also marked booking channel as required and the 
made a note that return date and time are 
defaulted to the next day; changed wording in 
flows No Car Class Returned (to no rates for car 
class returned), No Account Rates Are Found, 
Car Class Not Present in Account Rate Plan, and 
Car Class Not Present in Standard Rate Plan to 
return emptied out fields rather than 0.00; took out 
2.2.1 1 Multiple Billing Types in Agreement; added 
into req pro 

Allison Bruhn 


Confidential 


©Enterprise Rent-A-Car ? 2000 


Page 2 


Version: <L0> 

1 Date: <dd/mmm/yy> 

<document identifier> 


Table of Contents 

1. Retrieve Rates 4 
1.1 Brief Description 4 

2. Flow of Events 4 

2.1 Basic Flow 4 
2.1.1 Use Case Begins 4 
2. 12 Information Needed For Rate Retrieval 4 

2. 1 .3 Validate Dates and Branch 4 

2.1.4 Rate Source 4 

2. 1 .5 Agreement Found 5 

2.1.6 Calendar Day 5 

2.1.7 Charge Items 5 

2.1.8 Text Messages 5 

2.1.9 Rules 5 

2.1.10 Returned Rates 5 

2.1.11 The use case ends 5 

2.2 Alternative Flows 5 

2.2.1 No Rates for Car Class Returned 5 

2.2.2 Check availability 5 

2.2.3 Re-Rating 6 
2.2.3.1 One or More Charge Items.. • 6 

2.2.4 No Agreement Found 6 

2 .2 .5 No Account Rates Are Found 6 

2.2.6 Multiple Billing Types 6 

2.2.7 Tiered Rates 6 

2.2.8 Staggered Rates 6 

2.2.9 24 Hour Billing Cycle 6 

2.2.10 Using Account Type To Retrieve Rates From Standard Type 6 

2.2.10.1 Car Class Not Present In Account Rate Plan 6 

2.2. 1 0.2 Car Class Not Present In Standard Type Rate Plan 6 

3 . Special Requirements 7 
3.1 GDS Response Time 7 

4. Preconditions 7 

4. 1 User must be logged on 7 

4.2 Identify booking channel 7 

5: Post-Conditions 7 

5.1 < Post-condition One > 7 

6. Extension Points 

6.1 <Name of Extension Point> 7 

7. Questions 7 


Confidential 


©Enterprise Rent-A-Car, 2000 


Page 3 



Version: <1.0> 


Date: <dd/mmm/yy> 

<document identified 

Business Use-Case Specification: Retrieve Rates 

1 , Retrieve Rates 


1.1 Brief Description 



The purpose of this use case is to show what the system does to retrieve the appropriate rates 
requested for a rental transaction. The rental system will provide the rates system with specific 
information from the transaction in order to successfully retrieve rates. 

2. Flow of Events 

2.1 Basic Flow 

2.1.1 Use Case Begins 

This use case begins when the rental system initiates a request for rates for a specific rental 
transaction. 

2.1.2 Information Needed For Rate Retrieval 

The rental system provides the rates system with information from the transaction to retrieve 
rates. Any other criteria entered from beiow may affect what rate is retrieved. (See Rate 
Hierarchy for additional information.) 

• The pickup group branch (req uired) 

• The pickup date (required) 

• The pickup time (required) 

• The return date (default will be set to one day after the pickup date) 
« The return time (default will b e set to one day after the pickup time) 

• The car class which the rental system wants priced 

• List of all of the optional products and charge items seated by the user in the 
. transaction 

• Rate source (this is either an a ccount number or a standard type) 

• Booking channel/location (reauired-see Identify Booking Channel in Pre-Conditions) 

Note: From 2.1,3 through 2.1.9, the rental system passes information to the rates system which 
becomes the responsibility of the pricing engine. However, they are left in this use case for now 
as reference. 

2.1.3 Validate Dates and Branch 

Next, the system validates the information bv confirming that the return date is the same or after 
the pickup date. It also confirms that the pickup branch is a rental branch . 

2.1.4 Rate Source 

Next, the s ystem uses th e rate source to search for a contractual agreement or a standard 
agreement. An agreement is found and the user case mntimifts at the next step. If no 
agreement is found see alternate flow N o Agreement Found. The system searches for this rate 
agreement in effect for the pickup branch an d the pickup date. If no agreement is found, the 
system uses th e branch infor mation to fin d the next lev el of the rate hierarchy (see Additional 
Information Rate Hierarchy^ and sear ches again for a rate agre ement in effect for the pickup 
branch for the pickup date. The system continues this process through the hierarchy until an 
agreement is found, or the hierarchy lev els are exhausted. If no account rates are found see 
alternate flo w No Accoun t Rates Found . 
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2.15 Agreement Found 

Once an agreement is found for the branch and pickup date, the system checks for the number of 
billing types included. 

If there is oniv one billing type, the rates system ret rieves the bi lling cycle associated with the 
billing type . if there are multiple billing types see alternate flow Multiple Billing Types . 

2.1.6 Calendar Day 

If the billing cycl e is calendar dav. the rate s system proceeds to retrieve the vehicle daily rate for 
the car class provided . If the billing cycle is 24 hour see alternate flow 24 Hour Billing Cycle . 

2.1.7 Charge Items 

After the daily rate for the vehicle is retrieved, t he rate for each additional charge item specified is 
retrieved, alon g with its cha rge fre quency. When ho urly, weekly, or monthly are available, these 
are not select ed because only daily is reouired on a calendar day transaction, however values 
like " per rental" are valid . feee FAQ: Charge Frequency ). If re-rating one or more charge items 
applies see alternate flow Re-Rating . 

2.1.8 Text Messages 

The system retrieves all messages associated with the rate source or the agreement . See FAQ 
Text and Rufes) 

2.1.9 Rules 

The system retrieves all rules associated with the rate source and with the agreement . SeeFAQ 
Text and Rufes) 

The responsibility of the pricing engine ends and information is returned to the rental 
system. 

2.1.10 Returned Rates 

The rates for all ch arge items are returned along with all messages and rules associated with the 
rate source or the agreement . If no account rates are found see alternate flow No Account Rates 
Are Found . If no rates for car class are returned see alternate flow No Car Class Returned . If no 
agreement is found see alternate flow No Agreement Found . 

2.1 .1 1 The use case ends 

The re guested information i s returned including any and all rates, messages, and rules based on 
the criteria the rates system used to retrieve rates . 

2.2 Alternative Flows 

2.2. 1 No Rates for Car Class Returned 

If no rates for c ar class are re turned (a null value rather than 0.00). allow the user to re-enter one 
or more of the criteria needed for the svstem to retrieve a rate . If multiple rates are returned the 
user can choose to select one. 

2.2.2 Check availability 

This is only done during the make a reservation process. For example, if a renter has made a 
reservation to pick up a certain car class on Monday and plans to return it the following Monday 
but changes the pick-up date to a day later for the same car class, the system would not check 
availability. However, if the reservation pick up date was changed to two days prior to the original 
pick up date, the system would check for availability. Or, if the renter kept the same pick up date 
but changed the car class the system would check for availability (see FAQ-Availability Check). 
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2.2.3 Re-Rating 

2.2.3.1 One or More Charge Items 

The user mav request to have one or mor e charge itemf s^ re-rated due to changes in the 
transaction or the addition of a charoe item after th e reservation has been made or the ticket has 
been opened . in the case of the vehicle, the availability should not be checked once the 
reservation has been made, provided that no changes in the date of pickup have been made. 

2.2.4 No Agreement Found 

If the system cannot find an agreement, the user can re-enter one or more of the criteria needed 
for the system to find an agreement or the use case ends. 

2.2.5 No Account Rates Are Found 

if no account rates are found, return 0. 00 and allow the user to select another rate source . (See 
FAQ No Rates Returned for NatRes) 

2.2.6 Multiple Billing Types 

The system returns multiple billing types. Based on which billing type is selected the system will 
then retrieve the billing cvcle associated with the billing type . The use case continues at the 
main flow calendar day . 

2.2.7 Tiered Rates 

If the applicable rates are tiered, then the system will return rates in this fashion. 

2.2.8 Staggered Rates 

If the applicabl e rates are stag gered, then the system will return rates in this fashion. 

2.2.9 24 Hour Billing Cycle 

If the billing cvcle is 24 hour T the system uses the billing type and the pickup and return davs to 
return an hourly, daily, weekly, and monthly rate . 

2.2.10 Using Account Type To Retrieve Rates From Standard Type 

If the account tvoe has a matching standard tvpe. use it. Otherwise use the standard type 
mapped to the account type . 

2.2.1 0.1 Car Class Not Present In Account Rate Plan 

If the car clas s is not present in the a ccount rate plan, the system searc hes the account's profile 
for information about whet her or not to automatically look in the standard plans for the rate or to 
sto p the ra te search and return a null value . (Perofs pricing engine most likely going to handle this) 

2.2.1 0.2 Car Class Not Present In Standard Type Rate Plan 

If the car class is not present in the standard type rate plan, return a null value f rather than Q.QO ). 
(Perot's pricing engine most likely going to handle this) 


Confidential 


©Enterprise Rent-A-Car, 2000 


Page 6 



Version: <1.0> 


Date: <dd/mmm/yy> 

<document identified 


3. Special Requirements 

3.1 GDS Response Time 

Our contracts with GPS systems require that a response be returned to a rate request within 
seven seconds . 

4. Pre-conditions 

4.1 User must be logged on 

• The user is log ged into ECARS 2.0 application and ECARS has validated the user has 
privileges to perform rate verification. 

• The user has access to the iocal machine. 

• The user has access to t he network . 

4.2 Identify booking channel 

System must have identified which distribution channel is being used to retrieve the rates, and for 
what purpose (make reservation, update reservation, open ticket, open ticket using a reservation) 

5. Post-Conditions 

5.1 < Post-condition One > 

6. Extension Points 

6.1 <Name of Extension Point> 

7. Questions 
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1. Request Special Rates 
1.1 Brief Description 

This document provides the scenarios used to obtain and select Special Rates. This use case is 
an extension to the Retrieve Rates UC for the step where the User enters the Rate Source. In this 
case the user has requested to obtain "Special" Rates, which can be defined as: Rates, which are 
available for a limited period of time, example: Weekend Special. Actual implementation details 
are contained in the Consolidated Products and Rates - IT 3. SUP documents. 

2. Flow of Events 

2.1 Basic Flow 

C | 2.1.1 User requests the "Special Rate". 

H j 2. 1.2 Pricing Engine Determines that the Special Rate is applicable. 
2.13 Rates displayed to the User. 

2.2 Alternative Flows 

2.2. 1 Res Location not Pickup Branch, PU is Prior to Qualification 

2.2.1 .1 User Request Special Rate 

2.2.1 .2 Pricing Engine finds no Special Rates for the Criteria Entered. 

2.2.1 .3 System Displays "No Rates Found Message" 

2.2.1 .4 User Clears Message 

2.2.1 .5 User Selects Rate Source other than "Special". 

2.2.2 Res Location is Pickup Branch, Pickup DT prior to Qualification 
2.2.2. 1 User Request the "Special Rate" 

2.2.3 Pricing Engine finds Special Rates, but all the Qualifications on PU are not met. 

2.2.3.1 System Display Message to the User: "The entered P/U D/T is outside the Qualifications for the 
Special Rate. Do you wish to extend the qualification and use the Special Rate anyway?" 

2.2.3.2 User elects to Extend the Special Rate. 

2.2 .3 .2 . 1 User elects not to extend Special Rates. 

2.2.3 .2.2 System Clears Message and Returns to Rates test Window. 
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2.2.4 User elects to Re-Allocate days at the Special Rate and Days at the Standard Retail Rate. > 


3- Special Requirements 

3.1 Location Based Flexibility (Information Purposes Only) 

3.1.1 If the Reservation Source is different than the Pickup Branch all Pickup qualifications must be 
met. 

3.1.2 If the Reservation Source is the Pickup Branch, then the user will have the option to extend the 
special rate when the Pickup is prior to the stated Pickup Qualification. 

3. 1.3 If the Rental is extended beyond the Special Period, standard Retail Rates will be used for the 
additional days. 

4. Pre-Conditions 

User has filled in the necessary criteria to obtain rates 

5. Post-Conditions 

6. Extension Points 
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ECARS 2.0 Architecture 

1. Introduction 

The ECARS 2.0 application is an operational system designed to support Enterprise Rent-a-Car's 
Rental line of business. The application will ultimately replace the existing AS/400 based 
ECARS 1 .0 application. However, due to external dependencies, integration to the existing 
system is an integral part of the new ECARS application. 

The following document is intended to describe the overall architecture of the ECARS 2.0 system 
at a conceptual and logical level. For physical implementation specifics reference the documents 
specified in Appendix A. 

2. Conceptual Architecture 

At it's highest level, the ECARS 2.0 system is composed of seven main components; the 
Application Client, Web Application; AS/400 Interface Programs, AS/400, ECARS 1.0 to 
ECARS 2.0 Synchronization, ECARS 2.0 Database, and the Rates Pricing Engine. 

The Application Client represents any client to the application. This includes the web based user 
interface, or external application interfaces. The Web Application encompasses the ECARS 2.0 
business logic as well as the logic to render the pages for the user interface. The AS/400 
interface programs are used to leverage functionality from the existing AS/400s or to synchronize 
data with them. The AS/400s process several applications including the current ECARS 1 .0. The 
ECARS 1 .0 to ECARS 2.0 Synchronization is used to synchronize data from the AS/400 to the 
ECARS 2.0 application. The ECARS 2.0 Database serves as the main data storage for the 
ECARS 2.0 application. Finally, the Rates Pricing Engine is the component used to generate all 
Rate related information for ECARS 2.0 and future external applications. Each of these 
components will be discussed in more detail in the subsequent sections. 
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Figure 1 - ECARS 2.0 Conceptual Architecture 

3. Logical Architecture 
3.1 Application Client 

3.11 Thin Client 

The ECARS 2.0 application has been designed to utilize a thin client for the user interface. The 
generated HTML pages are generally lightweight with no applets and minimal JavaScript. These 
pages are displayed in an Internet Explorer browser running on a terminal server at the branch. 
This allows for minimized deployment complexities while leveraging currently available 
technologies. 


While most features utilize traditional Web technologies, the ECARS system has a requirement to 
know the physical location of a request. This requirement is not inherently supported using Web 
technologies. Therefore, the ECARS application leverages a script running on the Terminal 
Server to access the Active Directory and create a cookie with the user's physical location. This 
cookie is retrieved by the ECARS application to determine the physical location of the request. 
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3.1.2 External Clients 

The Enterprise Rent-a-Car environment consists of several applications whose combined 
responsibility is to support the day-to-day operations of the company. The ECARS 2.0 
application has been designed to leverage some of these existing assets as well as provide 
functionality to others. These external clients support differing levels of communication and 
integration. Therefore, to support the wide range of application interfaces, the ECARS 2.0 
application has been designed to support four main methods of integration: JMS Messaging, 
RMI, Web Services, and the WebLogic/Tuxedo Connector. 


Currently, JMS messaging is being considered for asynchronous calls from external clients. The 
JMS message would be consumed by a Message Driven Bean within the ECRS 2.0 Web 
Application and processed accordingly. 

Alternatively, for synchronous calls, the ECARS 2.0 Application can support RMI and Web 
Service calls. However, the Web Service approach is currently favored over direct RMI calls. 
This is due to the looser coupling between applications using the Web Service approach. 

Finally, the WebLogic/Tuxedo Connector will be utilized to provide an interface for Tuxedo 
based applications to leverage ECARS 2.0 functionality. This allows WebLogic to appear as a 
Tuxedo domain and thus allows a Java process to appear as a Tuxedo service. Therefore, 
external Tuxedo services will be able to call a Java process using the same method as it would to 
call a different Tuxedo service. 


3.2 ECARS 2.0 Web Application 

The ECARS 2.0 Web Application has been designed to leverage Java, J2EE and browser based 
technologies. Its implementation relies heavily on industry standards, design patterns, and best 
practices. When looking at the application functionality, it can be segregated into four Logical 
tiers that are deployed onto several physical tiers. 
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Figure 2 - ECARS 2.0 Web Application Tiers 


Physical Tiers 


The Client tier represents a thin client user interface. This interface contains very little business 
logic and consists solely of HTML pages with JavaScript. These pages are rendered within an 
Internet Explorer browser and are generated from Java Server Pages. 


The Control tier is responsible for generating the HTML/JavaScipt pages, managing navigation, 
transforming data, and performing field level validations (e.g. did the user enter a numeric value 
in a numeric field). 


The Business tier consists of the logic for the application business rules, validations, and data 
interactions. These are implemented using EJBs and Java Classes. 


The Data tier represents the data storage for the application 
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Currently, these four Logical tiers are deployed onto several Physical tiers. The Client resides 
within a Web Browser running on the Terminal Server and a Thin Client. The Control and 
Business Logical Tiers are currently deployed on a cluster of WebLogic servers. The Data Tier 
resides on an Oracle 8i database. Due to the dynamic nature of the application, no static content 
resides on the Web Server cluster. However, while the Web Server provides no application 
functionality, it is required to support load balancing and failover for the WebLogic cluster. 
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3. 2. 1 Web Application Components 
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Figure 3 - ECARS 2.0 Web Application Components 


Confidential 


©Enterprise Rent-A-Car, 2000 


Page 10 of 26 


Rental Redesign 

Version: 1.0 

ECARS 2.0 Architecture 

Date: 12/20/01 10:25 AM 

ECARS 2.0 Architecture Overview 


3.2.1.1 Action 

The Action encapsulates any processing logic that was requested or required prior to displaying a 
page or when leaving a page. For example, if a request is made to save a reservation, an Action 
will delegate to other objects and ensure the data is aggregated correctly. If so, the Action will 
initiate a call to a Use Case Manager to ultimately save the data. 


3.2.1.2 Action Factory 

The Action Factory is responsible for creating instances of Actions and pooling them for reuse. 

3.2.1.3 Adapter 

The Adapter is a data mapping mechanism to transfer data between the Form and the Domain 
Object. 

3.2.1.4 Browser 

HTML and JavaScript based user interface. 

3.2.1.5 Custom Tag 

Custom Tags are Java objects used to encapsulate presentation logic required to present dynamic 
content from the JSP. Example tags include a tag to create an HTML table of drivers, a color 
indicator based on reservation status, etc. 

3.2.1.6 DB 

The DB contains all of the SQL for transactions with the database. 

3.2.1.7 DB Factory 

The DB Factory transforms data between Domain Objects and Model Objects. One Domain DB 
Factory may call another one to support more complex transactions. For example, to save a 
reservation, a Reservation Domain (with associated Driver Domain, Bill To Domain, etc.) will be 
passed to a Reservation DB Factory. The Reservation DB Factory will then delegate to other 
factories as required to process other Domains such as Driver and Bill To. The DB Factory may 
also serve as a data cache if required. 

3.2.1.8 Domain Object 

The Domain Object is a data holder for information passed through the system. These are 
typically business objects such as a Reservation or a Driver. 

3.2.1.9 Form 

The Form is a data holder for information required during a user session. Typically, these objects 
are more course-grained than a Domain Object and represent aggregated data required for the 
display of a page. 
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3.2.1.10 JSP 

The JSP is responsible for creating an HTML page based on dynamic data. It does so by 
executing on the application server with a combination of HTML, JavaScript, and calls to Custom 
Tags. 


3.2.1.11 MainServlet 

The Main Servlet is responsible for receiving all requests made from the browser. The Main 
Servlet takes data from the request and places it into a Form for processing. While doing so, the 
Main Servlet will utilize helper classes to perform field level validations such as a valid date 
entered in a date field. The actual application processing is delegated from the Main Servlet to an 
Action. 


3.2.1.12 Model 

The Model is an object representation of a result set from a data source. These objects are used to 
provide an additional layer of isolation between the data structure and the Domain Objects within 
the application. 


3.2.1.13 Session 

The Session (not pictured above) is used to temporarily store data specific to a user's interaction 
with the system. Typically, Forms or Domain Objects will be stored with the Session to enable 
application processing. These objects are typically removed when a user leaves a page and the 
data is no longer required. 


3.2.1.14 Use Case Manager 

Encapsulates a call from the Action to the Application Layer. 

3.2. 1 . 1 5 Use Case Manager Bean 

The Use Case Manager Bean is responsible for implementing business logic in the Application 
Layer. The Use Case Manager Bean is responsible for managing the complete transaction with 
the database. 


3.2.1.16 Validator 

Validator objects are responsible for validating a Domain Object. Validators are specific to a 
Domain Object and can be "chained" together to enable stricter validation rides. 

3.2.1.17 Web View 

The Web View is an object representation of an entry in the XML file. 
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3.2.1.18 Web Views 

Web Views is the object responsible for parsing the XML configuration file and creating the 
appropriate Web View objects. This object also maintains a pool of Web View objects; therefore 
the XML file does not need to be re-parsed for each request. 


3.2.1 .19 XML Configuration File 

This file contains properties for all page requests. Information specified in the file for each page 
includes: possible navigation destinations, page field elements, the Enter Action, and the Exit 
Action. 
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3. 2. 2 User Request Processing 

The following sections describe the lifecycle of a typical user request on the ECARS 2.0 Web 
Application. 


3.2.2.1 Control Processing 

As illustrated in Figure 4 below, the MainServlet serves as the main entry point into the ECARS 
2.0 Web Application. When the MainServlet receives a user request, it first retrieves an instance 
of the WebViews object. It then retrieves the WebView object corresponding to the user request. 
If this is the first request into the application, the WebViews object will parse the application's 
XML configuration file to generate a pool of WebView objects. 


Once the MainServlet has retrieved the WebView object, it will get a list of Form Fields from the 
WebView. These Form Fields represent fields on the web page and map directly to attributes in 
the web page's corresponding Form Object. The MainServlet uses the list of Form Fields to get 
data out of the HTTPServletRequest and set it in the appropriate Form. While doing so, the 
MainServlet may use Form Field Validators to validate that the data is the correct type (e.g. 
numeric data for a numeric field). 


After the data is processed from the request and placed into a Form object, the MainServlet 
retrieves the Action that corresponds to the page that the user is exiting. The MainServlet then 
delegates to the Action for any application processing that may be required when the user leaves 
the page. For example, if a user chooses to save some data, this logic would mostly likely be 
encapsulated into the exit processing for the save page (details of the page exit processing is 
described in Section 3.2.2.2). 


If the page exit processing was not successful, the MainServlet will process the error using the 
application's exception handling components. Otherwise, the MainServlet will retrieve the 
Action corresponding to the page that the user would like to navigate to. Similar to the page exit 
processing, The MainServlet will delegate to the Action for all processing that is required prior to 
displaying the page. For example, the retrieval of data for display to a user could be encapsulated 
into the page enter processing (details of the page exit processing is described in Section 3.2.2.3). 
Then, to display the page, the MainServlet forwards or redirects the request to the corresponding 
JSP. 
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3.2.2.2 Page Exit Processing 

As mentioned above, the page exit processing is responsible for the application logic when a user 
exits a page in the application. Usually this entails operating on some data that the user has 
entered or modified on the screen. In earlier functionality, the MainServlet has processed this 
user data and put it into a Form object. Since this object represents screen data and not business 
objects, the data can be difficult to process and validate. Therefore, the Action utilizes an 
Adapter to take the data from a Form and places it in a Domain object. The Action can then 
begin to process the data or pass it to the UseCaseManager for detailed business processing or for 
data storage/retrieval. (This process will be described in more detail in section 3.2.2.4) 


UseCaseManaaer 



Figure 5 - ECARS 2.0 Web Application Page Exit Processing 


3.2.2.3 Page Enter Processing 

The page enter processing is typically used to initialize content for pages and to retrieve data for 
display. To achieve this, the Action delegates to the UseCaseManager to retrieve required data in 
the form of one or more Domain Objects. The Action then uses an Adapter to transform the data 
into a Form for display by the JSP. 
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Figure 6 - ECARS 2.0 Web Application Page Enter Processing 


3.2.2.4 Business Processing 

The business processing is responsible for performing business validations, executing defined 
business processes, and managing transactions with the data sources. The process begins when 
the UseCaseManagerBean receives a request from a UseCaseManager or an external system. 
Any data passed UseCaseManagerBean is validated using a Validator object. 


If valid and the business process requires saving data, the UseCaseManagerBean delegates to a 
DB Factory and passes the Domain Object. The DB Factory processes the Domain Object and 
transforms the data into a Model or set of Model classes. Additionally, if required, the DB 
Factory may delegate some processing to an additional DB Factory. Once data has been placed 
in a Model, it is passed to a DB object to execute the SQL or corresponding data access method. 


Similarly, if the business processing requires retrieval of data the DB Factory delegates to the DB 
for data access. The DB object places the result set into one or more Model objects. The DB 
Factory then maps the Model data into one or more Domain Objects and passed back to the 
requestor. 
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3.3 AS/400 

The existing ECARS application runs on seventeen AS/400s. The functionality is distributed by 
user base such that one AS/400 serves the Midwest, one serves the North East, etc. 

3.4 AS/400 Interface Programs 

3. 4. 1 ECARS 1. 0 Rates Interface 

The ECARS 1 .0 Rates Interface is a temporary interface required to support the initial 
Reservation pilot functionality. Eventually the Rates Pricing Engine will replace this interface. 
The current interface consists of UNIX Tuxedo services, AS/400 Tuxedo services, and AS/400 
Wrapper programs. To make this architecture fault tolerant and highly available, the UNIX 
Tuxedo service serves as a Domain Gateway to the AS/400 Tuxedo services. This configuration 
allows the architecture to take advantage of Tuxedo's Domain to Domain communication model 
rather than having to build the failover into the ECARS 2.0 Web Application. 


A typical transaction for the ECARS 1 .0 Rates Interface would begin with the ECARS 2.0 Web 
Application making a request to a UNIX Tuxedo service through Jolt 1 . 


ECARS 2.0 
Web Application 


UNIX Tuxedo 
Services 


AS/4&& 


AS/400 Tuxedo 
Services 


Rates Wrapper 
Program 


Figure 8 - ECARS 1.0 Rates Interface 


The current architecture is designed to use Jolt for aii Java to Tuxedo requests. While this architecture works, it introduces 
complexity due to the required addition of UNIX Tuxedo. To reduce these issues, the WebLogic/Tuxedo Connector (WTC) is 
currently being evaluated as a potential replacement for Jolt. Using the WTC, WebLogic will act as a Tuxedo Domain and will 
therefore eliminate the need for a separate UNIX Tuxedo domain. 
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3.4.2 ECARS 2.0 to ECARS 1.0 Synchronization 

When data is saved in the ECARS 2.0 application, it often must be synchronized with data on the 
AS/400. Based on business requirements, this process is implemented asynchronously using a 
polling technique 2 . The process starts when data is saved in the ECARS 2.0 Web Application. 
At this point an entry is put into a queue for processing. A Java thread running within the Web 
Application periodically reads the queue and begins to process the entry. Because the data 
formats and structures are different on the two systems, the Java process begins by retrieving 
additional data and performing data transformations. Once complete, the Java thread sends the 
data to a UNIX Tuxedo service through Jolt. Similar to the ECARS 1 .0 Rates Interface, the 
UNIX Tuxedo serves as a Domain Gateway to on one of seventeen AS/400 Tuxedo Domains. 
Then, the data is passed by the AS/400 Tuxedo service to a wrapper program on the AS/400. The 
AS/400 wrapper program performs AS/400 specific validations and the saves the data. A return 
code is then returned to the Java process to indicate the success or failure of the transaction. 
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Figure 9 - ECARS 2.0 to ECARS 1.0 Synchronization 

3.4.3 ECARS 1.0/2.0 Cross Platform Record Locking 

The ECARS 1 .0 application maintains a lock table to indicate record locks within the AS/400 
system. External applications and other ECARS 1 .0 processes verify the lock status in the table 
prior to locking the record. If a lock does not exist, the system enters a record in the table and 
then obtains a physical lock on the record in the lock file. 


2 


Future implementations may eliminate the polling technique in favor of a JMS based asynchronous solution. This will increase 
performance by reducing the data retrieval requirements and by reducing the network traffic associated with polling. The JMS 
based solution, however, would continue to utilize the Tuxedo based architecture. 
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In contrast, the ECARS 2.0 system uses time based logical locks on all transaction based data. 
This strategy has been implemented by adding a timestamp and user ID to the database record to 
indicate when and by whom a lock has been acquired. Currently, the system allows a user to hold 
a lock for up to thirty minutes, however this is configurable to adjust the default lock time. 


Since the ECARS 1 .0 and ECARS 2.0 systems will be active at the same time, there is a 
requirement to support cross platform record locking. Furthermore, due to the diverse AS/400 
programs that use the lock file, it is desired to minimize the impact on the existing programs. 
Therefore, to accomplish this requirement, the ECARS 1 .0 record lock file will serve as the 
master record lock for cross platform locks. 


For a given transaction within the ECARS 2.0 system, the application would first inspect the 
logical lock within the ECARS 2.0 database. If the application were able to acquire the lock, it 
would then attempt to acquire the AS/400 lock via the ECARS 2.0/1 .0 record lock process. The 
ECARS 2.0/L0 record lock process would inspect the lock file to see if the transaction was 
locked. If not, the process would enter a record in the lock table and then acquire a physical lock. 
The process acquiring the lock would be configured to expire based on the same logical lock time 
established for the ECARS 2.0 system. 
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Figure 10 - ECARS 1.0/2.0 Cross Platform Record Locking 
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3.5 ECARS 1 .0 to ECARS 2.0 Synchronization 

The ECARS 1 .0 reservation data is processed thru Wrapper program(s) on the AS/400. This 
information is then passed to a transformation file, which contains the cross-reference data for the 
ECARS 2.0 and ECARS 1 .0 reservation number mapping etc. There are individual triggers that 
map one to one with e*Gate scripts. These E*Gate scripts use the cross-reference file(s) for 
writing to the e*Gate input transaction file IX001P. The rules specific transformation scripts 
will then write the data to the ECARS2.0 Oracle Data base. 
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3. 5. 1 AS/400 Stored Procedures 

The AS/400 stored procedures are used to poll unprocessed data from an AS/400 transaction file. 

3.5.2 Polling Scripts 

The polling scripts are used to facilitate the execution of the AS/400 stored procedures. The data 
being pulled from the North American machines varies only in the size of the last fixed length 
field from the European machines. 

3.5.3 Routing Script 

The Routing Script is used to direct incoming files from the IQ to the correct cascade. The 
Routing Script first loops through each record and matches the current record to the previous 
records. 

3. 5. 4 Cascades and Table Level Integrations 

The lower two levels of the three-tier dart script architecture consists of the cascade scripts and 
the table level integration scripts. 

3.5.5 Cascade 

The cascade scripts basically execute each of the BULK Table Level Integrations scripts in the 
correct sequence. Depending on the data sorted from the Routing Script the cascade will receive 
the records contained in a single fixed length string. All data received will be from the same file, 
for the same operation, and be for North America or European. The Routing Script executes the 
cascades file. 

3. 5. 6 Table Level Integrations 

At this level, required and relevant data are mapped. There are 2 basic types of table level 
integration scripts: Bulk and Line mode. Bulk scripts are the primary method for data 
integration. Bulk scripts using the DBMSJSQL package attempts to insert or updates up to 750 
records at one time. Bulk script will not return an error, because in the event of an error the Bulk 
script will execute the equivalent Line script. The Line scripts are the secondary method for data 
integration. Line scripts attempt to update or insert a single record at a time. In the event of an 
error, the script will send an event to the e*Gate monitor for each record that contained an error. 

3.5. 7 Monk Dart Scripts 

There are fours types of monk scripts used in this project architecture Routing, Cascade, Table 
Level Integrations, and Poll scripts. Most DART scripts are categorized as either Bulk or Line 
Table Level Integrations. Each type of script follows a common flow of logic and the only 
difference from script to script in a particular category is the transformation of data. 

3. 5. 8 Oracle Stored Procedures 

Both Bulk and Line mode dart scripts utilize Oracle PL/SQL procedures. Every monk DART 
script declares a specific stored procedure and assigns it to a connection handle variable. Bulk 
mode dart scripts call Bulk mode stored procedures, and Line mode DART scripts declare Line 
mode stored procedures. DART scripts then map required and relevant data to the outbound data 
structure (ETD). The data collected by the outbound data structures are then assigned to unique 
parameters in the stored procedures. 
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Each line mode within the Oracle PL/SQL stored procedure implements 1 parameter, which 
consists of a single row of data. Each data segment is processed individually, then the stored 
procedures exit after performing an insert or an update operation. 


3.6 ECARS 2.0 Database 

The ECARS 2.0 Database is an Oracle 8i database with multiple schemas within the instance. 
Currently, the schemas include ones for transaction, transaction reference, geographic, 
Group/Branch, vehicle, and rates pricing engine data. 

3.7 Rates Pricing Engine 

The Rates Pricing Engine is responsible for determining rental rates for given input parameters. 
The ftmctionality has been written using Pro*C with the ECARS 2.0 database. The Rates Pricing 
Engine functionality will be accessed by the ECARS application using UMX based Tuxedo 
services. 
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Appendix A - Further Reading 

Web Application 

Exception Handling 

\\FSCORP00\corp public\APPS\Ecars 20\Prog ram ArtifactsVArchitecture Program AitifactsVDesign 
Guidelines\Exception Handling .doc 


Logging 

\\FSCORP00\corp public\APPS\Ecars 20\Pr o gram ArtifactsVArchitecture Pr ogram ArtifactsVDesign 
Guidelines\Logging Guidelines.doc 

Internationalization 

\\FSCORP00\corp public\APPS\Ecars 20\Pro gram ArtifactsVArchitecture Program Artifacts\Design 
GuidelinesMnternationalization Guidelines.doc 

eLocation 

\\FSCORP00\corp public\APPS\Ecars 20VDev e lopment ProiectsVReservation Primary Use CasesVArtifactsVOO 
Modeling\Elocale\ELocationPOC.doc 

\\FSCORP00\corp public\APPS\Ecars 20\ D evelopment Proiects\Reservation Primary Use Cases\Artifacts\OQ 
Modeling\Elocale\ELocation Overview.doc 

Printing 

\\FSCORP00\corp public\APPS\Ecars 20\Development P roiects\Reservation Primary Use Cases\Artifacts\OQ 
Modeling\Print\Print Qverview.doc 

Application Locking 

\\FSCORP00\corp public\APPS\Ecars 20\ Development Proiects\Ap pli cation Navigation and 
Securitv\Artifacts\OQ Modeling\Service Catalog - Application Locking.doc 

ECARS 2.0 to ECARS 1-0 Svnchrnnfaatinii 

\\FSCORP00\corp publi c\APPS\Ecar s 20\Pro gr am Artifacts\Architecture Program ArtifactsUpplication Interface 
Processes\R eservation Rental GUI to Legacy Supp ortdoc 
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Screen Action Specification 

Introduction 

This document will describe the behavioral characteristics associated with the Insurance Details screen. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 

Drivers - Insurance Detail 



DRIVERS 


pames Atteberry 
Additional Drivers: 2 


REFERRAL 


Account Name 
Contact Name 


DATES/RATES 


08/27/2001; ECAR 
Daily Rate; ASD 


BILL TO 


[Account Name 
[Contact Name 


11997 Dodge Avenger 
f Shop Account Name 


Notes Taken: 1 
Changed: 08/27/2001 


bnvers - Insurance Detai 


Smith, 

Chris 


Cloud, 

Kevin 


Driver 


i 


Other Address 


Insurance Detail 


Cash Qualification 


"Insurance Details* 
Carrier 


Agent 


Phone 


Insurance Company Contact 


Policy Number 


Expiration Date 


(MM/DD/YYYY) 


| Comprehensive Deductible 

Collision Deductible 

Liability? 

iL_i L_ 



Assigned Risk? 

Lienholder Policy? 








Tkt - 234567 Cbk - 383221 


Figure 1 ■ Insurance Detail 


3, Reservation Number 


3.1 Behavior 


This area shows the unique reservation number that has been assigned to the newly created reservation. 
The reservation number is 6 alphanumeric characters long. If another reservation is open, its reservation 
number will displayed in this area as well The user will have the ability to have to 3 reservations open at a 
time. A hyperlink will be available on the reservation numbers of the reservations that are NOT currently 


Confidential 


©<Company Name> 5 2000 


Page 5 


<Project Name> 

Version: <1.0> 

Supplementary Specification 

Date: <dd/mmrn/yy> 

<document identified 


being displayed. For the reservation that is currently displayed, the reservation number will not have a 
hyperlink available. This is to allow the user to navigate between the open reservations. 

3.2 Validation 

None identified at this time. 

3.3 Business Exceptions 

If the user tries to open a 4 th resevation, the system will display a message stating, "A maximum of 3 
reservations may be displayed/ 5- 

3.4 System Exceptions 

None identified at this time. 

4. Insurance Details 

4.1 Carrier 

4. 1 1 Behavior 

This is an alphanumeric field. 

4.1.2 Validation 

No validation is necessary. See Rules regarding when the field is required. 

4.1.3 Business Exceptions 

None have been identified at this time. 

4.1.4 System Exceptions 

None have been identified at this time. 

4.2 Agent 

4.2.1 Behavior 

This is an alphanumeric field. 

4.2.2 Validation 

No validation is necessary. The field is optional. 

4. 2. 3 Business Exceptions 

None have been identified at this time. 

4.2.4 System Exceptions 

None have been identified at this time. 

4.3 Phone 

4.3.1 Behavior 

This is an alphanumeric field. It should comply with the standard phone number field formatting. 
[06/05/2001- To date, no European considerations have been noted (waiting on update to Use Case). 

Validation 

The field is optional. 
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See the Special Phone Number Requirements at the end of the document for validation 
specifics.) ~~~ 


4. 3. 2 Business Exceptions 

None have been identified at this time. 

4.3.3 System Exceptions 

None have been identified at this time. 

4.4 Insurance Company Contact 

4.4.1 Behavior 

This is an alphanumeric field. 

4.4.2 Validation 

No validation is necessary. See Rules regarding when the field is required. 

4. 4. 3 Business Exceptions 

None have been identified at this time. 

4.4.4 System Exceptions 

None have been identified at this time. 

4.5 Policy Number 

4.5.1 Behavior 

This is an alphanumeric field, 

4.5.2 Validation 

No validation is necessary. See Rules regarding when the field is required. 

4. 5. 3 Business Exceptions 

None have been identified at this time. 

4. 5. 4 System Exceptions 

None have been identified at this time. 

4.6 Expiration Date 

4.6.1 Behavior 

Only numeric values and delineating characters will be accepted into this area. 

Associated with this field is a calendar function that allows the user to select a date from a calendar screen 
instead of entering a value. Clicking on the calendar icon will display the screen; once a date is selected 
from the screen the Expiration Date field will be populated with the appropriate date. ~~ 

See Rules regarding when the field is required. 

4.6.2 Validation 

No validation is necessary. The field is optional. 
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4. 6. 3 Business Exceptions 

None have been identified at this time. 


4.6.4 System Exceptions 

None have been identified at this time. 

4.7 Comprehensive Deductible 

4.7.1 Behavior 

This is a numeric field. 

4.7.2 Validation 

No validation is necessary. See Rules regarding when the field is required. 

4. 7. 3 Business Exceptions 

None have been identified at this time. 

4. 7. 4 System Exceptions 

None have been identified at this time. 

4.8 Collision Deductible 

4.8.1 Behavior 

This is a numeric field. 

4.8.2 Validation 

No validation is necessary. See Rules regarding when the field is required. 

4. 8. 3 Business Exceptions 

None have been identified at this time. 

4. 8. 4 System Exceptions 

None have been identified at this time. 

4.9 Liability? 

4.9.1 Behavior 

The responseis either 'Yes' or 'No', but the response is optional. There is no default value. 

4.9.2 Validation 

No validation is necessary. See Rules regarding when the field is required. 

4. 9. 3 Business Exceptions 

None have been identified at this time. 


4.9.4 System Exceptions 

None have been identified at this time. 
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4.10 Assigned Risk? 

4.10.1 Behavior 

The response is either 'Yes' or 'No', but the response is optional. There is no default value. 


4.10.2 Validation 

No validation is necessary. The field is optional. 


4.10.3 Business Exceptions 

None have been identified at this time. 

4. 10.4 System Exceptions 

None have been identified at this time. 

4.11 Lienholder Policy? 

4.11.1 Behavior 

The response is either 'Yes' or 'No', but the response is optional. There is no default value. 

4.11.2 Validation 

No validation is necessary. The field is optional. 

4.11.3 Business Exceptions 

None have been identified at this time. 

4.11.4 System Exceptions 

None have been identified at this time. 

5. Button Line Area 

5.1 Back Button 

The Back button will take the user to the main Driver screen for the currently selected driver. 

5.17 Validation 

None identified at this time. 

5.1.2 Business Exceptions 
None identified at this time. 

5.1.3 System Exceptions 
None identified at this time. 

5.2 Complete Button 

5.2.7 Behavior 

The Complete button will initiate a save of the transaction. All validations will be performed, returning any 
errors to the user. If there are no errors, the transaction is saved, and the user is returned to the Reservation 
home page. ™~ 

5.2.2 Validation 

None identified at this time. 
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5. 2. 3 Business Exceptions 
None identified at this time. 

5.2.4 System Exceptions 
None identified at this time. 


6. Rules 

6.1 Re quired Fields 

These fields are onlyrequired if information is present in any one of the following fields: Carrier, Policy 
Number, Expiration Date, Collision Deductible, Comprehensive Deductible Liability, Insurance Company 
Contact' If the systenideterm ines that any of the listed fields are missing information, the systemwill 
present the userwith a feedback message listi ng the inco mplete required fields and directing them to " 
complete them. 

6.2 Saving 

Because none of the information on the screen is re quired, the user can leave the screen a t any time during 
me course of makingoreming the reservation or while opening, editing or closing the open ticket. The 
save is completed whenthe user saves the reservation or ticket 

6.3 Tabbing 

Tabbing between fields should be in the order that they are in this document 

7. Security 

The user must have the appropriate security level to access this screen. 


8. Special Phone Number Requirements 

8.1 Overall Requirements 

The databasehas fields for the area code and phone number. 

Area codes and phone numbers in North America are numeric only. Legacy phone numbers for North 
America are numeric only. 

Area codes and phone numbers JnEurope may be characters or numbers. Legacy phone number for 
Europe are both characters and numbers. 

8.2 Renter Specific 

When navigating to a form with phone number fields, or when t he page is s ubmitted, the phone number 
Helds will be formatted a ccording to the system locale. 

8.3 Insurance Phone Number 

The user will have a single field to enter the phone number. 

For North America, the user may enter numbers only. All special characters will be ignored during 
formatting, any characters willrejult in an error. A space is considered a special character 
For Europe, the user may enter characters or numbers. At least one special character must be entered. The 
Erst special character will indicate the break between the area code and the phone number. All other 
special characters are ignored. 
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8.4 Phone Number masking rules by country: 

• The format for North America is (XXX) XXX-XXXX 

• The format for Germany is: XXX.X.XX.XX.XX 

The area code may vary in length, and is determined by a special character entered by the user to indicate 
where the break occurs. If the length of the phone number (not including the area code) is odd, the firsf " 
character is placed by itself as shown above, the remaining characters are paired up. If the length is even, 
all characters are paired up. 

• The format for Ireland and the UK is XXX.XXX.XXX.XXX.X 

The area code may vary in length, and is dependent on the user entering a special character between the 
area code and phone number. The characters following the area code should be grouped in threes with aiiy 
remaining characters grouped at the end. 
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The application saves the Date/Time, Status, Type, Note text and Created By data at the time the note is 
committed to the database. ~~ 

Type = Callback 

Status == reservation/ticket status as of note creation 


4.2.1.2 Validation 

There must be data present in the Notes text field. 

4.2.1.3 Business Exceptions 

None have been identified at this time. 

4.2.1.4 System Exceptions 

None have been identified at this time. 

4.2.2 Cancel button 

4.2.2.1 Behavior 

This button will dismiss the Add Note screen without saving any data. 

4.2.2.2 Validation 

If data has been entered the following feedback message is displayed; "Are you sure you want to exit and 
lose the entered information?" Two options are presented, Yes and No. Yes will dismiss the screen and 
not save the data, No will take the user back to the Add Note screen. 

The default button selection is "No". 

4.2.2.3 Business Exceptions 

None have been identified at this time. 

4.2.2.4 System Exceptions 

None have been identified at this time. 

5. View Note (Figure 3 - View Note) 

This is a read only screen . 

5.1 Data 

5.1.1 Behavior 

This is a listing of the values associated with the selected note, this includes; 

• Date/Time 

• Status 

• Type 

• Created By 

• Arms Message Status 

• Note text 

The Note text field should be large enough to display the entire 510 characters as defined in the database. 

5.1.2 Validation 

No validation is necessary. 
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5.1.3 Business Exceptions 

None have been identified at this time. 


5.1.4 System Exceptions 

None have been identified at this time. 

5.2 Button Line Area - View Note 

5.2.1 Print button 

5.2.1.1 Behavior 

This button will essentially print a screen print of the View Note screen . 

5.2.1.2 Validation 

No validation is necessary. 

5.2.1.3 Business Exceptions 

None have been identified at this time. 

5.2.1.4 System Exceptions 

None have been identified at this time. 

5.2.2 Close button 

5.2.2.1 Behavior 

This button will dismiss t he View N ote screen . 

5.2.2.2 Validation 

None have been identified at this time. 

5.2.2.3 Business Exceptions 

None have been identified at this time. 

5.2.2.4 System Exceptions 

None have been identified at this time. 

6. Rules 

6.1 Required Fields 

The Note text field is required for creating a note. Feedback messages will be presented, as defined 
previously in t his document when attempting to save a note without the required information . 

6.2 Saving 

A note must be defined before the data can be saved to the database . 

7. Security 

The user must have the appropriate security level to access this screen . 
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Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the Notes screen. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 


Screen Print 


U Notes - Microsoft Internet Explorer provided by Enterprise Pent -a-Lar 



Referral sum 1 
Referral sum 2 


jDates summary 1 
f Dates summary 2 


Bill-To summary 1 
Bill-To summary 2 

Vehicle/Shop 1 
Vehicle/Shop 2 


I Notes summary 1 
INotes summary 2 


07/03/2001 Car is at Joe's Oarage 
3i22PM 


CLOSE 


CALLBACK ECARS2.0 
USER 


07/02/2001 Does not like red cars. This show? the first two lines of 
2;22PH the notes section. (2 @ 45 charl... 


OPEN 


SYSTEM SYSTEM 


SENT 


07/01/2001 Reservation Created 
1:22PM 


RESERVATION SYSTEM SYSTEM SENT 



Notes screen 


Figure 1 - Notes 
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m 

Ci 
111 
01 
Ci 
^1 
hi 

si 

111 
III 
0! 

Ci 


Aj|Add Note - Microsoft Internet Explorer pro... 


i 


22 





Note: 


I 


lAdd Note screen 


Figure 2 -Add Note 
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Date: 7/02/2001 2:22PM 
Status: Open 
Type: System 
Created Byi System 
Arms Msg: Sent 
Note: 


Does not like red cars. This shows the first two lines of the 
notes section. (2 8 45 char) 

The text area shown here is big enough to show 
the entire database field without scrolling. 



Note screen 
Figure 3 - View Note 
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Date/Time 

Note 

Status 

Note Type 

Created By 

ARMS Msg 

07/01/2001 
i:22PM 

Reservation Created 

Res 

System 

System 

Sent 

07/02/2001 
2:22PM 

Does not like red cars. This shows the first two lines of the 
notes sertion.(2 @ 45 char) 

Open 

System 

System 

Sent 

07/03/2001 
3:22PM 

Car is at Joe's Garage 

Close 

Callback 

ECARS 2.0 User 




Records Found: 3 


ilss 


■ - \ 



Print All Notes report look 
Figure 4 - Print All Records 


3. Notes (Figure 1 - Notes) 

3.1 Type 

3.11 Behavior 

This is a drop down field containing the follow ing domain values; 

• Callback 

• System 

The default va lue is "All". The summary list is filtered b v the item selected from th e values list. The 
Status drop down list should be taken into consideration when filtering the summary list. 

3.12 Validation 

No validation is necessary. 

3. 1 3 Business Exceptions 

None have been identified at this time. 
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3. 1.4 System Exceptions 

None have been identified at this time. 


3.2 Status 

3.2.1 Behavior 

This is a drop down field containing the following domain values; 

• Reservation 

• Open 

• Close 

The default value is "AH". The summary list is filtered by the item selected from the values list. The 
Type drop down list should be taken into consideration when filtering the summary list. 

3.2.2 Validation 

No validation is necessary. 

□ 3.2.3 Business Exceptions 

$ None have been identified at this time. 

Ill 

W 3.24 System Exceptions 

N f None have been identified at this time. 

M 1 3.3 Summary List 

IU 3.3.'/ Behavior 

SSI 2 

Ml The result list, as describe in the use case, will have a static column display sequence. AN 

111 columns need to have the capability to be sorted, ascending and descending. The user selects a 

Q! Reservation/Ticket by clicking on the hyperlink associated with the desired data row. The 

CS summary list will be populated with the latest note appearing first and the earliest note appearing 

M last (descending order sorted by date/time). ~ " ~ 

An ellipse (...) should be placed at the end of the note text field if the verbiage contained in the 

note exceeds 80 characters. ^ - 

The user must have the appropriate security to view/edit the Reservation/Ticket 
selected. 

This list contains the application standard for lists regarding sorting by column. 
The 'ARMS Msg' column header does not directly translate for Germany; rather, 
it is 'ARMS'. 

3.3.2 Validation 

None have been identified at this time. 

3. 3. 3 Business Exceptions 

None have been identified at this time. 

3. 3. 4 System Exceptions 

None have been identified at this time. 
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3.4 Button Line Area 

3.4. 1 Print All Records button 

3.4.1.1 Behavior 

The Print All Records button will essentially generate an html report and send it to the printer. This will 
allow the user to print the entire collection of notes associated with a reservation/ticket. This report will not 
be sent to the screen, it will only be sent to the printer. (See Figure 4 - Print All Records.) 

3.4.1.2 Validation 

No validation is necessary. 

3.4.1.3 Business Exceptions 

None have been identified at this time. 

3.4.1.4 System Exceptions 

None have been identified at this time. 

3.4.2 Add Note button 

3.4.2.1 Behavior 

The Add Note button will display the Add Note screen for data input (See Figure 2 - Add Note.) 

3.4.2.2 Validation 

No validation is necessary. 

3.4.2.3 Business Exceptions 

None have been identified at this time. 

3.4.2.4 System Exceptions 

None have been identified at this time. 

3. 4. 3 Previous Button 

3.4.3.1 Behavior 

The Previous button will take the user to the Vehicle/Shop screen within the same transaction. 

3.4.3.2 Validation 

No validation is necessary. 

3.4.3.3 Business Exceptions 

None have been identified at this time. 

3.4.3.4 System Exceptions 

None have been identified at this time. 

3.4.4 Next Button 
3 AAA Behavior 

The Next button will take the user to the Drivers screen within the same transaction. 
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3.4.4.2 Validation 

No validation is necessary. 

3.4.4.3 Business Exceptions 

None have been identified at this time. 

3.4.4.4 System Exceptions 

None have been identified at this time. 

3.4.5 Complete Button 

3.4.5.1 Behavior 

The Complete button will initiate a save of the transaction. All validations will be performed, returning any 
errors to the user. If there are no errors, the transaction is saved, and the user is returned to the Open Ticket 
home page. 

3.4.5.2 Validation 

No validation is necessary. 

3.4.5.3 Business Exceptions 

None have been identified at this time. 

3.4.5.4 System Exceptions 

None have been identified at this time. 

4. Add Note (Figure 2 - Add Note) 

4.1 Note 

4.1.1 Behavior 

This is a free form text field in which the user may enter data. 

4.1.2 Validation 

There must be data present in order for the note to be saved. 

4. 1.3 Business Exceptions 

None have been identified at this time. 

4. 1.4 System Exceptions 

None have been identified at this time, 

4.2 Button Line Area - Add Note 

4.2.1 OK button 
4.2.1.1 Behavior 

If data is not present in the Notes text field the feedback message reads, "Please enter a Note if selec tingjo 
Save." Two options are presented, OK and Cancel. Ok will take the user back to the Add Note screen for 
data entry, Cancel will dismiss the Add Note screen. ~~ " 

Ok will be the default selection. 
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Screen Action Specification 


1. Introduction 

This document will describe the behavioral characteristics associated with the Open Ticket Search screen, 
and its related screens. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 



Figure 1 - Initial Entry - Simple Search 
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Rats* Tooh Hv\? 


Entemrise* ECARS Application - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 

*■* „ — • . — ■• ... 


Open Ticket Search ^ - ' 


\ Group: 

1 1 01 - ST LOUIS 
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Advanced Search 
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I — 
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Renter Last Name: 

k_ ... 
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I . . _ r 
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Figure 2 - Simple Search with Search Results 
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2 Errfeiprise* ECARS Applicatioi Micro iff. Internet Explorer provided by ^Enterpri ;Rj ti >-Car 


Contracts CatW>5 ' Pates Tools Help 


Open Ticket Search 


Group: 


Branch: 


[alT 
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I Ticket Number: 
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1 RO/PO/C!aim Number: 

i! L j 
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Simple Search 


Renter First Name: 
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Renter Telephone Number: 
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^Enterprise* ECARS Application - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 


Open Ticket Search 
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LADUE RENTAL 0101 


Sa m ple Search 


il Ticket Number: 


|| RO/PO/C!aim Number: 


Renter Last Name: 

- kz . : . 

Unit Number: 


Renter First Name: 


Unit Plate Number: 


Renter Telephone Number: 
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Kg 
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Items 1 - 3 of 3 found 


First Prev 1 Next Last 


Figure 4 - Advanced Search with Search Results 
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Figure 5 - Calendar selection 


3. Group 
3.1 Behavior 

This search criterion will be limited to active rental groups. The selection of "All" is also 
included, and will appear at the top, or first, in the list . This search criteria area will be a 
drop-down box. The users would also like to have the ability to type a character, alpha or 
numeric, into the criteria area and have the drop down list position to the character. (If 
the user enters an "H" the drop down list would position to the first string beginning with 
"H" in the list) The default item should be the group associated to the terminal locale . 
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3.2 Validation 

The items appearing in the list are static; the user cannot add items to the list 
dynamically. 

3.3 Business Exceptions 

The user should not be allowed to view or select a group outside of security parameters. 

3.4 System Exceptions 

None identified at this time. 

4. Branch 

4.1 Behavior 

This search criterionwill be limited to active branches The selection of "AH" is also included, and will 
arroear at the ton, or first, in&elist This search criteria area will be a drop-down box. The users would 
also like to have the ability to tvpea character, alpha or numeric, into the criteria area and have fce_drop 
down list position to the character . (If the user enters an "H" the drop down list would position to the first 
string beginning with "H" in the list) 

The default item should be the branch associated to the terminal locale . Branch items appearing in the list 
will be limited to the Group item selected. Once the sele cted Group i tem has changed, the first tonjAlil 
will be the default selection itenT 

4.2 Validation 

The items appearing in the list are static; the user cannot add items to the list 
dynamically. 

4.3 Business Exceptions 

The user should not be allowed to view or select a branch outside of security parameters. 

4.4 System Exceptions 

None identified at this time. 

5. Ticket Number 

5.1 Behavior 

This search area will be an alphanumeric field. It will return exact matches for the characters entered . 
When this sear ch criterion is used, any other entered criteria will be ignored by the system, Alphanumeric 
values will be accepted into this jiekL 

5.2 Validation 

None identified at this time. 

5.3 Business Exceptions 

None identified at this time. 

5.4 System Exceptions 

None identified at this time. 

6. Renter Name L ast / First 
6.1 Behavior 

This search criteria area will be an text field containing an implied wildcard after the entered criteria . The 
First Name field will not be enabled until search criteria has been entered into the Last Name field. JHrns,, 
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the First Name field will n ot be access ible via either the tab key or the mouse unless Last Name datajs 
present. 

It should be noted that either Last Name or Last Name and First Name used in 
combination, is considered to be just one search criteria. 

It will return exact matches for the characters entered and will continue with other text 
strings that match the characters entered, but are of a longer length (an implied wildcard). 
Example: If the Last Name search criteria entered were "Smith", you would receive back 
every open ticket with "Smith" in the Last name. You would also receive every character 
string that matched "Smith" for the first 5 characters, but was longer than five characters. 
Given this, you would also receive, "Smither", "Smithson", "Smithy", etc. These longer 
character matches would be alphabetically ascending after the exact character matches of 
equal length. The First Name field behaves in the same manner. 

6.2 Validation 

None identified at this time. 

6.3 Business Exceptions 

None identified at this time. 

6.4 System Exceptions 

None identified at this time. 

7. Renter Telephone Number 

7.1 Behavior 

This search criter ia area will be an alphanumeric field. It will not be fo rmatted for presentation p urposes. 
Returns exact matches for the characters e ntered . A phone number is considered to be the entire number 
including area code. Example: In the United States, it would be the 3 digit area code, plus the seven digit 
phone number. (Country Code is not considered a part of the phone number.) The search will be on all 
phone number fields associated with the Driver/Renter. Curre ntly, these ar e Home, Office and Other. 

7.2 Validation 

None identified at this time. 

7.3 Business Exceptions 

None identified at this time. 

7.4 System Exceptions 

None identified at this time. 

8. RO/ PO/Claim Number 

8.1 Behavior 

This search criteria area will be an alphanumeric field. 
Returns exact matches for the char acters entered"! 

8.2 Validation 

None identified at this time. 

8.3 Business Exceptions 

None identified at this time. 
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8.4 System Exceptions 

None identified at this time. 

9. Unit Number 


9.1 Behavior 

This search criteria area will be an alphanumeric field. 
Returnsexact matches for the characters entered . 

9.2 Validation 

None identified at this time. 

9.3 Business Exceptions 

None identified at this time. 

9.4 System Exceptions 

None identified at this time. 

10. Ope n Ticket Date 

10.1 Behavior 

Only numeric values will be accepted into these areas. The search to the database will be 
inexact numeric, time stamp match . Associated with this field, is a calendar function 
that allows the user to select a date from a calendar screen, or similar feature, instead of 
entering a value (Figure 5 - Calendar selection). Clicking on the calendar icon will 
display the screen, once a date is selected from the screen the Open Ticket Date field will 
be populated with the appropriate date. 

Returns exact matches for the characters entered. It will not be formatted for presentation purposes. The 
user may enter delineating characters, but these will be stripped out before searching the database to find an 
exact date match. 

10.2 Validation 

None identified at this time. 

10.3 Business Exceptions 

None identified at this time. 

10.4 System Exceptions 

None identified at this time. 

11. Unit Plate Number 

11.1 Behavior 

This search criteria area will be an alphanumeric field. 
Returns exact matches for the characters entered. 

11.2 Validation 

None identified at this time. 

1 1 .3 Business Exceptions 

None identified at this time. 
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11.4 System Exceptions 

None identified at this time. 

1 2. Bill-To/Shop Name/Number Group 

This group of controls includes the Bill-To/Shop Name and the Bill-To/Shop Number 
radio buttons as well as a criteria text box. 

12.1 Behavior 

This search criteria area will be an alphanumeric field regarding the text field. The Bill- 
To/Shop Name radio button will be the default selection upon screen entrv . 
When the Bill-To/Shop Name radio button is selected an implied wildcard will be added 
at the end of the entered search criteria. Example: If the Bill-To/Shop Name search 
criteria entered were "Smith", you would receive back every open ticket with "Smith" in 
the Bill-To/Shop name. You would also receive every character string that matched 
u "Smith" for the first 5 characters, but was longer than five characters. Given this, you 

p would also receive, "Smither", "Smithson", "Smithy", etc. These longer character 

p matches would be alphabetically ascending after the exact character matches of equal 

HI length. 

P I When the Bill-To/Shop Number radio button is selected it returns exact matches for the 

Ui characters entered. 

Y\ An entry into this field will search the Bill-To and Shop roles that an account (customer) 

y i may be and return all matches. Currently, the roles to which the search may be applied 

I, are "Shop" and "Bill-To". 

Ill 12.2 Validation 

H I None identified at this time. 

p 12.3 Business Exceptions 

I- b None identified at this time. 

12.4 System Exceptions 

Only one radio button can be selected at a given time. 

1 3. Search Results Area 

13.1 Behavior 

The result list will have a static column display sequence . All columns need to have the capability tobe 
sorted, ascending and descending . The user selects an Open Ticket by clicking on the hyperlink associated 
with the desired data row. 

The user must have the appropriate security to view/edit the open ticket selected. 

13.2 Validation 

None identified at this time. 

1 3.3 Business Exceptions 

None identified at this time. 

13.4 System Exceptions 

None identified at this time. 
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14. Advanced Search / Simple Search hyperlink 

14.1 Behavior 

By clicking on the Advanced Search hyperlink, the user is presented with the advanced 
search functionality (Figure 3 - Advanced Search). Alternatively, by clicking on the 
Simple Search hyperlink, the user is presented with the default search screen (Figure 1 - 
Initial Entry - Simple Search). Any search criteria entered when on the default search 
screen will be passed to the Advanced Search screen if/when accessed . If the user 
navigates to the Simple Search screen from the Advanced Search screen, any search 
criteria entered into the advanced criterion that is not found on simple search will be lost. 

14.2 Validation 

None identified at this time. 

14.3 Business Exceptions 

None identified at this time. 

14.4 System Exceptions 

None identified at this time. 

1 5. Results Feedback Line Area 

15.1 Behavior 

This feedback area provides the user with the search result list count as well as list 
navigation. The user may select the block of records available as returned by the invoked 
search criteria. These blocks are identified by sequential numbers, along with a First (I s 
block of records) and Last (last block of records). Also appearing will the Prev and Next. 
When negotiating through the result list the sequential numbers will change depending 
upon the block of records being viewed, other blocks of records can be accessed via the 
Prev and Next hyperlinks. For example looking at the Figure 2 - Simple Search with 
Search Results if the user selected Next, the sequential numbers listed will range from 2- 
6. If the user wishes to return to record block 1, they can either select First or Prev to 
view record blocks 1-5 again. 

15.2 Validation 

None identified at this time. 

15.3 Business Exceptions 

None identified at this time. 

15.4 System Exceptions 

None identified at this time. 

16. Button Line Area 
16.1 Behavior 

The Search image/button will invoke the search process, submitting the form to the 
server. The search can be invoked bv clicking on the button or the user u sing the enter 
key. 
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The Reset control will return the screen to its default state. 

The default state being 


area. 

The system should determine that no more than the set limit of three search criteria have 
been entered. 

16.2 Validation 

None identified at this time. 

16.3 Business Exceptions 

A limit ofthree search criteria may be entered. 

If TicketNumber is entered, all other search criteria are ignored . 

16.4 System Exceptions 

If more than three search criteria are entered the user should be presented with a feedback 
message stating "A limit ofthree search criteria may be entered, Please refine your 
search." 


17, Rules 

The Renter Name Last / First and Account Name search criteria have an implied wild card character placed 
directly after the entered text, all other search criteria fields on this screen are to be treated as exact matches 
with searching. 

The user may invoke the search without changing or adding any search criteria to the default screen entry 
criteria. The user may increase the scope of the search by selecting all groups and/or all branches, no 
detailed search criteria is necessary when using this screen. 

There is a limit ofthree search criteria on which a search may be executed. This does not include the Group 
and Branch selections. If more than three are entered the system will present to the user an appropriate 
feedback message stating that a maximum ofthree search criteria may be entered. This message will be 
displayed a form submittal. 

When there are not any matches to the input search criteria the user should be presented with a feedback 
message stating no items were found. This text should appear in the 0 listed below. 

1) If the search returns more open tickets than can be displayed on the screen at one time, then the 
system needs to present to the user the range of records they are viewing out of the total number of 
records 

All of the following search criteria, EXCEPT Ticket Number, will be limited to, or constrained by, the 
Group and Branch indicated or selected. 

18. Security 

The user must have the appropriate security level to access this screen. 
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Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the Open Ticket without 
Payment Use Case. This document also extends the screen action specification documents associated with 
the reservation iteration, which includes the following screens: 

• Driver 

• Additional Driver 

• Other Address 

• Insurance Detail 

• Cash Qualification 

• Referral 

• Bill-To 

• Vehicle / Shop 

• Dates / Rates 

• Notes 

• Application Locking 

The user enters the new ticket process via the menu Tickets:New. This process behaves in the same 
manner as the previously defined Reservation process, opening a new record as an open ticket rather than a 
reservation. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 
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2. Screen Prints 


<H E3846G 01 0i Enterprise* ECARS Application - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 




rPhone Numbers 
I Home: 


J 


Work: 


Extension: 


j Employer: 

| Other Phone and Type: 

;[~J 


-Home Address - 
Address: * 


ZIP: 


Country: 



[UNITED STAT§§ 

City: * 

State: * 

I 



_ . State 
issuing Country: Issued . * 


j UNITED STATf 


SSN: 


Date of Birth: 


Eye Color: * Height: * 

i nn 


Hair Color: * Weight: * 


ins 


Primary Payment Method: 



Figure 1 - Driver 


Confidential 


©Enterprise Rent-A-Car, 
2001 


Page 5 


ECARS2 


12/20/2001 


E384GG 0101 Enterprise^ ECARS Application - Microsoft ^Internet ^Enpiiorer provided by Enterprise Rent-a-Car 


| ^afiDaa s _ | venicie - ■ § touts. 


Additional Drivers: 1 

il 




Driver 



Figure 2 - Additional Driver 


*§j Complete - Web Page Dialog 



f ©complete 

|j C Complete - Unit Pend 

Ji O Complete - Pre-Write 


OK 


Can 



Figure 3 - Complete 


3. Driver 
3.1 Driver 

3.7.7 Behavior 

This screen primarily behaves in the same manner as in Reservation. The following fields are required for 
this process: 

■ Last Name 
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■ First Name 

■ Address 

■ gig 

■ Country 

■ 

• State 

■ License Number 

■ Expiration Date 

■ State Issued 

■ Date of Birth 

• Social Security Number 

• Height 

■ Eye Color 

■ Weight 

■ Hair Color 

All conditionally required fields and behaviors defined during the Reservation iteration apply 

3.1.2 Validation 

No validation is necessary. 

3. 13 Business Exceptions 

None have been identified at this time. 

3.1.4 System Exceptions 

None have been identified at this time. 

4. Additional Driver 

4.1 Additional Driver 

4.1.1 Behavior 

This screen primarily behaves in the same manner as in Reservation. The following fields are required for 
this process: 

• Last Name 

• First Name 

• Date of Birth 

The following fields are conditionally required for this process: 

• If License Number is entered then 

■ State Issued 

■ Expiration Date (Drivers License section) 

• If Address is entered then 

" Last Name 

■ First Name 

■ Zip 
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■ Country 

■ State 

All conditionally required fields and behaviors defined during the Reservation iteration apply. 


4.1.2 Validation 

No validation is necessary. 

4.1.3 Business Exceptions 

None have been identified at this time. 

4.1.4 System Exceptions 

None have been identified at this time. 

5. Complete 

The complete process primarily behaves in the same manner as that defined in the Reservation iteration 
with the exception of the items listed below. This includes corrfirmation dialogs and validations. 

5.1 Form 

5.1.1 Behavior 

Only one selection can be made. The default selection will be "Complete". 

The OK button will invoke the validation and save process. 

The Cancel button will dismiss the form, placing the user back to where they invoked the process. 

5.1.2 Validation 

Complete - When this option is selected all validations are invoked. This includes the required fields 
defined in the Driver and Additional Driver sections above as well as those conditionally required fields 
and validations defined in the Reservation iteration. During this iteration of the Open Ticket project a 
ticket will cannot be saved in this status due to the missing UnitPend data described below. Thus during 
this iteration a ticket can be saved in Complete - Pre-Write or Complete - Unit-Pend status only. 

Complete - Unit-Pend - When this option is selected all validations except those involving an assigned unit 
are invoked. This includes Unit Number and License Plate Number which currently do not exist in the 
screens beim used, these will be added to the Dates/Rates screen in future iterations of the Open Ticket 
project 

Complete - Pre-Write - When this option is selected the Drivers Last and First names along with the 
Billing Cycle from the Dates/Rates screen and only those validations that are conditional required 
information are invoked. These sets of validations are primarily defined in the Reservation use cases. 

If the user selects to save a ticket and it fails the necessary validation, the system will provide a feedback 
message listing the offending items. The user will then be allowed to save the ticket in a "lesser" open 
ticket status via the "Complete" button. 

5.1.3 Business Exceptions 

None have been identified at this time. 

5.1.4 System Exceptions 

None have been identified at this time. 
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6. Rules 


6.1 Required Fields 

Since this document is an extension of the screen action specification document defined in the Reservation 
and Open Ticket projects, the required fields and conditionally required fields along with all of the 
associated validations pertain to this document as well. 

6.2 Saving 

The save is completed when the user saves the ticket. When the ticket saves successfully the application 
will navigate to the Ticket Search screen. 

7. Security 

The user must have the appropriate security level to access the screens. 
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Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the Open Ticket Retrieve Rate(s) 
screens. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 


2. Open Ticket Retrieve Rates - Screens 


H Rates Hew - Microsoft Internet Exploiei provided by Enterprise Rent-a-Car 


File m Ifl tx>m>- US m 


Stop; ■ Retoh Htffte : ;■: Search i 


|B hie //A* /APPS/Ecais,2Q/Devdopment%2(^ 



Driver summary 1 
Driver summary 2 - Pickup 
Date: 


REFERRAL: 


Time: 



Referral sum 1 
Referral sum 2 


Dates summary 1 10/04*2001 9:00 AM 

Dates summary 2 


BILL- 10 


-Return 

1 Date: 

0/08/2001 


Time: 


[300 PM 


1 


DROP Elco ChevroJet 


-Rate Source- 
Account Name 


Bill-To summary 1 
Bill-To summary 2 j-Select- 

Rate Plan 


Account Number 


Rental Type 


Billing Cycle 


Vehicle/Shop 1 ] -Select - 
Vehicie/Shop 2 J: — ~ ~~~ 


-Unit Information — 
Notes summary i Vehicle Preferences 
Notes summary 2 

Unrt# 




... 



Top portion of Rates panel 
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file AW/APPS^cafs_20/T)evelopment%2u22^ 



Dates/Rates 


- Options 


Driver summary 1 
Driver summary 2 [^Select^ 


Referral sum 1 
Referral sum 2 


L 


RATES 


Dates summary 1 
Dates summary 2 


BILL-TO 


Bill-To summary 1 
Bill-To summary 2 


V EJil CLE /SHOP 


Vehicle/Shop 1 
Vehicle/Shop 2 


NOTES ■ 


Notes summary 1 
Notes summary 2 


-Unit Information" 

Vehicle Preferences 

Unit # License Plate # 


Last 6 of VIN 


2000 Chevrolet Impala 1CAR 


J 



Bottom portion of Rates Panel 
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|£ Rates New - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 



Start Charges if Different pop-up box 
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H Reservation Dates and Rates Screen Spec - Microsoft Word 
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Account Search Display 
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Units Available pop-up box 
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Get Rates display area 
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£| Rates New - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 


Bill-To summary 1 
Bill-To summary 2 


V F H T t. L iz J SHOP 


Vehicle/Shop 1 
Vehicle/Shop 2 


Notes summary 1 
Notes summary 2 


^_ ^ ^_ j Mcnth(y (12/22/2002 I )11 15 AM J [12/24/2002 |l 2 25 PM ' 


[999.99 [Weekly ' |1 2/22/2002 . |11 15 AM " [12/25/2002 |8 45PM 
[TT2 99 : }Weekly [12/22/2002 J [4 55PM 1 [12/25/2002 [9'OOPM 

- : ; p ;I [ _ 


05l 


JSLP 


|- Select- Jj f 


Expanded Coverages display area 


111 




3. Open Ticket Number 

3,1 Behavior 

This area shows the unique open ticket number that has been assigned to the newly created 
ticket. The ticket number is 6 alphanumeric characters long. 
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If another reservation or ticket is open, its reservation/ticket number will be displayed in this area 
as well. The user will have the ability to have up to 3 reservations/tickets open at a time. A 
hyperlink will be available on the reservation/ticket numbers of the reservations that are NOT 
currently being displayed. For the reservation/ticket that is currently displayed, the 
reservation/ticket number will not have a hyperlink available. This is to allow the user to navigate 
between the open reservations/ticket. 

3.2 Validation 

None identified at this time. 

3.3 Business Exceptions 

If the user tries to open a 4 th reservation, the system will display a message 
stating, "A maximum of 3 reservations/tickets may be displayed". 

3.4 System Exceptions 

None identified at this time. 


4. Pick Up Group and Branch Area 

4.1 Behavior 

This area will be defaulted to the terminal location group and branch. A group and branch are required and 
it will be displayed in the header information. 

4.2 Validation 

None, it will correspond to the PeopleSoft determined values. 

4.3 Business Exceptions 

None identified at this time. 

4.4 System Exceptions 

None identified at this time. 

5, Pick Up Date Area 

5.1 Behavior 

This area will be an alphanumeric field. It will not be formatted for presentation purposes. 

The user may enter delineating characters, but these will be stripped out before writing to 

the database. There should be a calendar function available which would allow the user to 

select a date from a calendar icon, or similar feature, instead of entering a value. If the 

user selects a date from the calendar icons, it will be displayed in the date area formatted 

appropriately by the locale. (As determined for all locale specific formatting.) 

It should initially default to the current date. 

5.2 Validation 

It will be a valid month, day and year combination. 
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5.3 Business Exceptions 

If the user enters or selects a Pick-up date which is prior to the current date t display a message 
"Pick-up date is prior to current date. Is this correct?" 

If the user enters or selects a Pick-up date which is in the future, display a message "Pick-up date 
cannot be in the future." 

A pick up date is required. If it is blanked out, not input or selected, display a message "Must 
specify a pick-up date". 

5.4 System Exceptions 

If not a valid month, day and year combination, the normal date in error message should 
be displayed. 

6. Pick Up Time Area 

6.1 Behavior 

In locales where time is shown by AM PM designation: 

This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute and 
AM/PM designation, and a maximum of Hour Hour Minute Minute AM/PM designation. i.e. 945A, 
would designate 9:45 in the morning. A leading zero may precede the hour, but is not required 
and will be removed before saving to the database. The minutes must be two numeric values. 
The AM/PM designation of "A" or "P" must also be indicated. The user may enter delineating 
characters, but these will be removed before saving to the database. 

In locales where time is shown by 24 hour designation: 

This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute, and 
a maximum of Hour Hour Minute Minute, i.e. 945 would designate 9:45 in the morning, 1425 
would designate 2:25 in the afternoon. A leading zero may precede the hour, but is not required 
and will be removed before saving to the database. The minutes must be two numeric values. 
The user may enter delineating characters, but these will be removed before saving to the 
database. 

it should initially default to the current time. 

6.2 Validation 

In locales where time is shown by AM PM designation: 

Time increments can range from 1200A to 1 159A and from 1200P until 1 159P. If an entry is not 
within these two ranges display "Must specify a valid time". 

In locales where time is shown by 24 hour designation: 

Time increments can range from 0000 to 2400. If an entry is not within this range display "Must 
specify a valid time". 

6.3 Business Exceptions 

A pick-up time cannot be selected if there is not a pick-date selected. If this is attempted, 
display a message "Must specify a pick-up date". 
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if the user enters or selects a Pick-up time which is prior to the current time, display a message 
"Pick-up time is prior to current time. Is this correct?" 

A pick up time is required. If the default value is removed, display a message 
"Must specify a pick-up time". 

It is possible to have a pick-up time in the future, but the pick-up date must be the same. 


6.4 System Exceptions 

None identified at this time. 

7. Pick Up Time Drop Down 

7.1 Behavior 

This drop down icon will display the time in 15-minute increments. When 
selected, it should be positioned to the V* hour increment immediately preceding 
the current time and format according to the locale's format. 

7.2 Validation 

None identified at this time. 

7.3 Business Exceptions 

A pick-up time cannot be selected if there is not a pick-date selected. If this is attempted, 
display a message "Must specify a pick-up date". 

A pick up time is required. If the default value is removed, display a message 
"Must specify a pick-up time". 

If the user enters or selects a Pick-up time which is prior to the current time, 
display a message "Pick-up time is prior to current time. Is this correct?" 

It is possible to have a pick-up time in the future, but the pick-up date must be the same. 

7.4 System Exceptions 

None identified at this time. 
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8. Start Charges if Different Button Function 

8.1 Behavior 

Selecting this function will present the user will a pop-up box showing date and time 
fields. Information entered in the pop-up box will be displayed under the Start Charges if 
Different button function. 

8.2 Validation 

See specific areas. 

The ok feature will save date and time if valid. 

The cancel feature will close the pop-up and not save entered information, if any. 

8.3 Business Exceptions 

See specific areas. 

8.4 System Exceptions 

None identified at this time. 

9. Start Charges if Different Date Area 

9.1 Behavior 

This area will be an alphanumeric field. It will not be formatted for presentation purposes. 

The user may enter delineating characters, but these will be stripped out before writing to 

the database. There should be a calendar function available which would allow the user to 

select a date from a calendar icon, or similar feature, instead of entering a value. If the 

user selects a date from the calendar icons, it will be displayed in the date area formatted 

appropriately by the locale. (As determined for all locale specific formatting.) 

It should initially default a blank. 

9.2 Validation 

It will be a valid month, day and year combination. 

9.3 Business Exceptions 

The start charges if different date must be greater than or equal to the pick-up date, and less than 
or equal to the return date. 

if the user enters or selects a start charges if different date which is prior to the Pick-up date, 
display a message "Start charges dates cannot be prior to pick-up date." 

If the user enters or selects a start charges if different date which is after the return date, display 
a message "Start charges dates cannot be after return date." 

9.4 System Exceptions 

If not a valid month, day and year combination, the normal date in error message should 
be displayed. 
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1 0. Start Charges if Different Time Area 

10.1 Behavior 

In locales where time is shown by AM PM designation: 

This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute and 
AM/PM designation, and a maximum of Hour Hour Minute Minute AM/PM designation.i.e. 945A, 
would designate 9:45 in the morning. A leading zero may precede the hour, but is not required 
and will be removed before saving to the database. The minutes must be two numeric values. 
The AM/PM designation of "A" or "P" must also be indicated. The user may enter delineating 
characters, but these will be removed before saving to the database. 

in locales where time is shown by 24 hour designation: 

This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute, and 
a maximum of Hour Hour Minute Minute, i.e. 945 would designate 9:45 in the morning, 1425 
would designate 2:25 in the afternoon. A leading zero may precede the hour, but is not required 
and will be removed before saving to the database. The minutes must be two numeric values. 
The user may enter delineating characters, but these will be removed before saving to the 
database. 

It should initially default to blank. 

10.2 Validation 

In locales where time is shown by AM PM designation: 

Time increments can range from 1 200A to 1 1 59A and from 1 200P until 1 1 59P. If an entry is not 
within these two ranges display "Must specify a valid time". 

In locales where time is shown by 24 hour designation: 

Time increments can range from 0000 to 2400. If an entry is not within this range display "Must 
specify a valid time". 

10.3 Business Exceptions 

A start charges if different time cannot be selected if there is not a start charges if 
different date. If this is attempted, display a message "Must specify a start charges if 
different date". 

The start charges if different time must be greater than or equal to the pick-up time, if the start 
charges if different date is equal the pick-up date. 

The start charges if different time must be less than or equal to the return time, if the start 
charges if different date is equal the return date. 

If the start charges if different date is equal to the pick-up date and the user enters or selects a 
start charges if different time which is prior to the Pick-up time, display a message "Start charges 
time cannot be prior to pick-up time" 

If the start charges if different date is equal to the return date and the user enters or selects a 
start charges if different time which is after the return time, display a message "Start charges time 
cannot be after return time" 
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10.4 System Exceptions 

None identified at this time. 

1 1 . Start Charges if Different Time Drop Down 

11.1 Behavior 

This drop down icon will display the time in 15-minute increments. When 
selected, it should be positioned to the % hour increment immediately preceding 
the current time and format according to the locale's format. 

11.2 Validation 

None identified at this time. 

1 1 .3 Business Exceptions 

A start charges if different time cannot be selected if there is not a start charges if 
different date. If this is attempted, display a message "Must specify a start charges if 
different date". 

The start charges if different time must be greater than or equal to the pick-up time, if the start 
charges if different date is equal the pick-up date. 

The start charges if different time must be less than or equal to the return time, if the start 
charges if different date is equal the return date. 

If the start charges if different date is equal to the pick-up date and the user enters or selects a 
start charges if different time which is prior to the Pick-up time, display a message "Start charges 
time cannot be prior to pick-up time" 

If the start charges if different date is equal to the return date and the user enters or selects a 
start charges if different time which is after the return time, display a message "Start charges time 
cannot be after return time" 

1 1 .4 System Exceptions 

None identified at this time. 


12. Return Date Area 

12.1 Behavior 

This area will be an alphanumeric field. It will not be formatted for presentation purposes. 

The user may enter delineating characters, but these will be stripped out before writing to 
the database. There should be a calendar function available which would allow the user to 
select a date from a calendar icon, or similar feature, instead of entering a value. If the 
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user selects a date from the calendar icons, it will be displayed in the date area formatted 
appropriately by the locale. (As determined for all locale specific formatting.) 
It should default to a blank area. 

12.2 Validation 

It will be a valid month, day and year combination. 

12.3 Business Exceptions 

A return date is required. 

If the user does not enter a date a message is displayed "Return date must be specified". 

The return date cannot be before the pick-up date. If it is, display message "Return date must be 
equal to, or after Pick-up date". 

12.4 System Exceptions 

If not a valid month, day and year combination, the normal date in error message should 
be displayed 

13. Return Time Area 

13.1 Behavior 

In locales where time is shown by AM PM designation: 

This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute and 
AM/PM designation, and a maximum of Hour Hour Minute Minute AM/PM designation. i.e. 945A, 
would designate 9:45 in the morning. A leading zero may precede the hour, but is not required 
and will be removed before saving to the database. The minutes must be two numeric values. 
The AM/PM designation of "A" or "P" must also be indicated. The user may enter delineating 
characters, but these will be removed before saving to the database. 

In locales where time is shown by 24 hour designation: 

This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute, and 
a maximum of Hour Hour Minute Minute, i.e. 945 would designate 9:45 in the morning, 1425 
would designate 2:25 in the afternoon. A leading zero may precede the hour, but is not required 
and will be removed before saving to the database. The minutes must be two numeric values. 
The user may enter delineating characters, but these will be removed before saving to the 
database. 

This should default to a blank area. 

13.2 Validation 

In locales where time is shown by AM PM designation: 

Time increments can range from 1200A to 1 159A and from 1200P until 1 159P. If an entry is not 
within these two ranges display "Must specify a valid time". 

In locales where time is shown by 24 hour designation: 

Time increments can range from 0000 to 2400. If an entry is not within this range display "Must 
specify a valid time". 
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13.3 Business Exceptions 

A return time is required. 

If the user does not enter a time a message is displayed "Return time must be specified". 

A return time cannot be selected if there is not a return date entered or selected. If this is 
attempted, display a message "Must specify a return date". 

If the return date is the same as the pickup date, then the return time must be later than 
the pickup time. If not, display a message "When pickup and return date are the same, 
return time must be later than pickup time". 

13.4 System Exceptions 

None identified at this time. 

14. Return Time Drop Down 

14.1 Behavior 

This drop down icon will display the time in 15-minute increments. When 
selected, it should be positioned to the % hour increment immediately preceding 
the current time and format according to the locale's format. 

14.2 Validation 

None identified at this time. 

14.3 Business Exceptions 

A return time is required. 

If the user does not enter a time a message is displayed "Return time must be specified". 

A return time cannot be selected if there is not a return date entered or selected. If this is 
attempted, display a message "Must specify a return date". 

If the return date is the same as the pickup date, then the return time must be later than 
the pickup time. If not, display a message "When pickup and return date are the same, 
return time must be later than pickup time". 

14.4 System Exceptions 

None identified at this time. 
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15. Change Return Location Button Function 

15.1 Behavior 

Selecting this function will present the user will a pop-up box that will show the default 
group, branch (to the terminal's location) and return method drop down listings and a 
return location text area. 

Only areas with changed information will be displayed under the Change Return 
Information button function. The terminal location default group and branch will NOT be 
displayed unless changes are made. 

15.2 Validation 

See specific areas. 

There are not any required areas. 

The ok feature will save selected or entered information. 

The cancel feature will close the pop-up and not save entered information, if any. 

15.3 Business Exceptions 

See specific areas. 

15.4 System Exceptions 

None identified at this time. 

16. Change Return Location Group 

16.1 Behavior 

This drop down listing will be limited to those groups that exist at any point in time. The 
selection of "All" is NOT included in the list. The users would also like to have the 
ability to type a character, alpha or numeric, into the criteria area and have the drop down 
list position to the character. (If the user enters an "H" the drop down list would position 
to the first string beginning with "H" in the list) 
This should default to the terminal location group. 

16.2 Validation 

The items appearing in the list are static; the user cannot add items to the list 
dynamically. 

16.3 Business Exceptions 

None identified at this time. 

16.4 System Exceptions 

None identified at this time. 

17. Change Return Location Branch 
17.1 Behavior 

This drop down listing will be limited to those branches that exist within the group at any point in time. The 
selection of "All" is NOT included in this selection list. The users would also like to have the ability to 
type a character, alpha or numeric, into the criteria area and have the drop down list position to the 
character. (If the user enters an "H" the drop down list would position to the first string beginning with 
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"H" in the list) 

Branch items appearing in the list will be limited to the Group item selected. Once the selected Group item 
has changed, the branch will be set to blanks. This will require the user to select a branch, at which rime the 
display area will be refreshed, repopulated and repositioned. 
This will default to the terminal location branch. 

17.2 Validation 

The items appearing in the list are static; the user cannot add items to the list 
dynamically. This list will be limited to the branches associated with the group selected. 

17.3 Business Exceptions 

None identified at this time. 

17.4 System Exceptions 

None identified at this time. 

18, Change Return Location Method 

18.1 Behavior 

This drop down listing will be limited to values associated with the return method, 
currently the valid values are: Branch, Drop and Ride Back in North America and 
Branch, Ride Back and Automatic Pickup (APU) in Europe. 

18.2 Validation 

The items appearing in the list are static; the user cannot add items to the list 
dynamically. 

18.3 Business Exceptions 

None identified at this time. 

18.4 System Exceptions 

None identified at this time. 

1 9. Change Return Location Text Area 

19.1 Behavior 

This will be a free form text area. 

19.2 Validation 

None identified at this time. 

19.3 Business Exceptions 

None identified at this time. 
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19.4 System Exceptions 

None identified at this time. 

20. Account Name Drop Down 

20.1 Behavior 

This area will be a drop down list of the Branch's short list, for North America. For 
everywhere else it will be the Group's Account list. If there are any of the 
following associated with the particular open ticket, they will appear at the top or 
beginning of the list in the following order. 

1) Any Bill-To Accounts 

2) Any Referral Accounts 

3) Any Shop Accounts 

The information displayed about an Account will be in the following order: 

1) Account Name 

2) Account Number 

3) Rental Type 

4) Owning Group/Branch 

5) Address 

6) City 

7) State 

8) Zip 

9) Telephone 

The Account Name in the display area will have a hyper-link which, when 
selected, will populate the Account Name, Account Number, Account Type and 
Rate Plan areas on the Dates and Rates panel. 

20.2 Validation 

None identified at this time. 

20.3 Business Exceptions 

If Account name or number is selected and the following account types are determined, 
then other areas will be defaulted to the values shown. 


20.4 System Exceptions 

None identified at this time. 
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21 . Account Number Area 

21.1 Behavior 

This area will allow entry of alphanumeric values. When there is a match, the system will populate 
the Account Name, Account Number, Account Type and Rate Plan areas on the Dates and Rates 
panel. The search will be executed as the user tabs off of the field. 

21.2 Validation 

None identified at this time. 

21 .3 Business Exceptions 

If there is not an exact match, then display a message "Account number does not exist." 

21.4 System Exceptions 

None identified at this time. 

22. Account Search Button 

22.1 Behavior 

Selecting this button will display the account search panel. See Referral Source Supplementary 
Specification for details. 

22.2 Validation 

None identified at this time. 

22.3 Business Exceptions 

None identified at this time. 

22.4 System Exceptions 
None identified at this time. 

23. Rate Plan Drop Down 

23.1 Behavior 

This area will be populated when an Account Name or Account Number has been selected. 
If there are multiple plans associated with an Account, it will list all of the rate plans associated 
with that Account, and the user must choose one. When there are multiple rate plans, the value 
"select" will appear in area so the user knows that there are multiple rate plans and selection of a 
single one is required. 

If there is only a single rate plan associated with and Account then the rate plan pop-up box will 
appear show all of the car classes and rates associated with that account. 

23.2 Validation 

None identified at this time. 
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23.3 Business Exceptions 

If no rate plans are associated with an Account then a message is displayed 4< No rates were found". 

23.4 System Exceptions 

None identified at this time. 

24. Rental Type Drop Down 

24.1 Behavior 

This area will be a drop down list of Rental types. 

Rental Type 

Insurance 

Bodyshop 

Dealership 

Retail 

Corporate 

Other 

Employee 

Government 

Fleet 

Truck 

Rideshare 

Walk-in 


24.2 Validation 

Any value selected is valid. 

24.3 Business Exceptions 

None identified at this time. 

24.4 System Exceptions 

None identified at this time. 

25. Billing Cycle Drop Down 

25.1 Behavior 

This area will initially default to the billing cycle associated with the Account and Rate Plan 

selected. It may be changed to anther value. 

Drop down domain values are Blank, 24 Hour and Calendar Day. 

25.2 Validation 

None identified at this time. 
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25.3 Business Exceptions 

See list in account name area for defaults, based on account. 

25.4 System Exceptions 

None identified at this time 

26. Car Class to Charge for Drop Down 

26.1 Behavior 

This area will be a drop down list that also allows entry of alphanumeric values. The drop down 
list will be comprised of the most commonly used car classes. The entry of alphanumeric values 
will be edited against a larger more comprehensive car class list. If there is a successful 
vehicle/unit search, this will be populated with that particular vehicle's car class. It is possible to 
change this value. 

Drop down list values 

Class and Type 

ECAR 

CCAR 

ICAR 

SCAR 

FCAR 

PCAR 

LCAR 

MVAR 

XFAR 

XPAR 

XXAR 

XVAR 

26.2 Validation 

None identified at this time. 

26.3 Business Exceptions 

If the values entered are not one of the ones listed below, a message is displayed "Must enter a valid cai 
class". 

Car Class Edit List of Values 

Class and Type 

MCAR 

MBAR 
MDAR 
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MXAR 

MSAR 

MTAR 

MWAR 

MVAR 

MFAR 

MPAR 

ECAR 

EBAR 

EDAR 

EXAR 

ESAR 

ETAR 

EWAR 

EVAR 

EFAR 

EPAR 

CCAR 

CBAR 

CDAR 

CXAR 

CSAR 

CTAR 

CWAR 

CVAR 

CFAR 

CPAR 

ICAR 

I BAR 

IDAR 

IXAR 

ISAR 

ITAR 

IWAR 

IVAR 

I FAR 

I PAR 

SCAR 

SBAR 

SDAR 

SXAR 

SSAR 

STAR 
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SWAR 

SVAR 

SFAR 

SPAR 

FCAR 

FBAR 

FDAR 

FXAR 

FSAR 

FTAR 

FWAR 

FVAR 

FFAR 

FPAR 

PCAR 

PBAR 

PDAR 

PXAR 

PSAR 

PTAR 

PWAR 

PVAR 

PFAR 

PPAR 

LCAR 

LBAR 

LDAR 

LXAR 

LSAR 

LTAR 

LWAR 

LVAR 

LFAR 

LPAR 

XCAR 

XBAR 

XDAR 

XXAR 

XSAR 

XTAR 

XWAR 
XVAR 
XFAR 
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XPAR 


26.4 System Exceptions 

None identified at this time. 


27. Unit/Vehicle Input Search Area 
27.1 Behavior 

This will be an alphanumeric input area, consisting of 3 areas. The Unit Number, the License 
Number and the last 6 Digits of the Vehicle Identification Number, (VIN). 


The Unit Number must be entered, with at least one of the other two. Using this information, the 
system will be able to determine the associated car class, for the rate source selected. 
If there is only a single rate plan associated with the car class and rate source then the system 
will return rates for that particular unit/vehicle and the rates associated with all applicable 
coverages, PAI, CDW and SLP. 


If there is more than one rate plan associated with the rate source, then the system will display all 
rate plans determined by the car class and allow the user to select a single rate plan. After a 
single rate plan is selected, then the system will return rates for that particular un\i/veh\c\e and the 
rates associated with all applicable coverages, PAI, CDW and SLP. 

At a minimum, we will need to return the associated Unit Number, Year, Make, Model and Car 
Class of the different vehicles. This information will need to be saved with the transaction also. 
It will also be displayed within the unit information box when retrieved The search will initiate when the 
user tabs off of the last field. 


27.2 Validation 

None identified at this time. 

27.3 Business Exceptions 

If the unit/vehicle selected belong to a car class, which is not associated with a rate plan for the designated 
rate source, then a message is displayed "Rate plan does not contain selected car class". 
If the user has not entered one of the required fields, display a message "Unit number and license plate 
number or last 6 of VIN required. 


27.4 System Exceptions 

None identified at this time. 

At a minimum, we will need to return the associated Unit Number, Year, Make, Model and Car 
Class of the different vehicles. This information will need to be saved with the transaction also. 
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28. Units Available Search Button Function 

28.1 Behavior 

Selecting this button will display the Units available search pop-up panel. 

The pop-up box will display: 
Group and branch drop down boxes. 

Unit number, License plate number and Last 6 of VIN input areas. 

A search function which will execute the search 

A display of the vehicles available table with columns: 

Year, Make, Model, Series, Car Class, License Plate Number and Location. 

The Group and Branch drop down boxes will default to the terminal location. 

The Unit Number, License Plate Number and Last 6 of VIN, will default to blank. Any one, two or all three 
may be used to search the Vehicle Data base. 

The vehicles available display will default display the available units at the terminal location default group 
and branch. 

28.2 Validation 

None identified at this time. 

28.3 Business Exceptions 

There must be at least one search criteria to execute a search, otherwise display a message "Must specify at 
least one search criteria". 

28.4 System Exceptions 

None identified at this time. 

29. Get Rates Button 

29.1 Behavior 

Selection of this button will have the system execute a search for rate plans associated with the information 
entered. 

29.2 Validation 

None identified at this time. 

29.3 Business Exceptions 

At a minimum there must be an Account Name or an Account Number to search for rates. If the user 
selects this button without one of these a message is displayed "Must specify account name or number". 

29.4 System Exceptions 

None identified at this time. 
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30. Rate Plan - Pop-Up Display Area 

30.1 Behavior 

This is a pop-up window that will display the rates of a rate plan associated with 
an Account. Information displayed is: 

Rate pop-up box columns and information: 

• Car Class 

• Daily - Rate and Mileage 

• Weekly - Rate and Mileage 

• Monthly - Rate and Mileage 

• Hourly - Rate 

• Mileage Charge 

Car class will have a hyper-link which will allow the user to select the rate they want. This will then 
populate the rates display area on the Dates and Rates panel. 

Validation 

None identified at this time. 
Business Exceptions 

If an Account has more than one rate plan associated with it, then this 
information cannot be displayed until the Rate Plan area has a value. 

If an Account has a single rate plan associated with it, then this information is 
displayed after the Account Name is selected or an Account Number is entered. 

If an Account has a single rate plan and there is a value in the Car Class area, 
and that car class is in the rate plan, then the rates display area of the Dates and 
Rates panel is populated with the appropriate information and the rate plan pop- 
up window is NOT displayed. 

If an Account has multiple rate plans and there is a value in the Car Class area, 
and there is not a value in Rate Plan area, a message should display "Must 
specify a rate plan". 

If an Account has a multiple rate plans, and there is a value in the Rate Plan area 
and there is a value in the Car Class area, and that car class is in the rate plan, 
then the rates display area of the Dates and Rates panel is populated with the 
appropriate information and the rate plan pop-up window is NOT displayed. 

If an Account has a single rate plans, and there is a value in the Car Class area, 
but that car class is not in the rate plan, then a message is displayed, "Rate plan 
does not contain selected car class". 
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If an Account has a multiple rate plans, and there is a value in the Rate Plan area 
and there is a value in the Car Class area, but that car class is not in the rate 
plan, then a message is displayed "No rates found for car class selected". 


30.4 System Exceptions 

None identified at this time 

31 . Rate Plan - Display Area 

31.1 Behavior 

This is a display area that will be populated with the rates associated with a 
particular car class of a rate plan associated with an Account. 
Information displayed is: 

• Car Class 

• Daily Rate 

• Daily Mileage 

• Weekly Rate 

• Weekly Mileage 

• Monthly Rate 

• Monthly Mileage 

• Hourly Rate 

• Mileage Charge 

• No Charge Check Box 

All of the information presented, except Car Class, has the ability to be edited or 
changed. 

There is an interaction between the Mileage Charge and the No Charge Check Box. If the 
No Charge Check Box is selected, then the Mileage Charge is set to zero and the area 
disabled. Unselecting the No Charge Check Box will enable the Mile Charge area for 
entering values. 


31.2 Validation 

None identified at this time. 

31.3 Business Exceptions 

Negative values may not be entered. If attempted, display message "Must specify positive 
amount". 

31 .4 System Exceptions 

None identified at this time 
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32. Coverages Area 
32.1 Behavior 

This will be a collapsible/expandable area to display the different coverages. There will be some 
sort of button functionality which will allow this area to be expanded or collapsed. In either state 
the selected coverages will be listed to the side of the button function. Values within area may be 
changed or edited. 

Each area will have a drop-down box to be able to select additional items. 

It is anticipated that the information to be displayed for each instance of the coverage is: 
Description 
Rate 

Rate Frequency 
Start Date 
Start Time 
End Date 
End Time 

All of this information will come from what is maintained in the Perot systems. 


32.2 Validation 

None identified at this time. 

32.3 Business Exceptions 

Negative values may not be entered in the rate area. If attempted, display message "Must 
specify positive amount". 

Dates may be changed, but cannot be beyond the Pick-up and/or Return date range. If 
this is attempted, display appropriate message, either "Start date cannot be before pick-up 
date" or "End date cannot be after return date". 

Similarly, Times may be changed, but cannot be beyond the Pick-up and/or Return time 
range. If this is attempted, display appropriate message, either "Start time cannot be 
before pick-up time" or "End time cannot be after return time". 


32.4 System Exceptions 

None identified at this time. 

33. Coverages - CDW Area 

33.1 Behavior 

This area will initially default to the amount of Collision Damage Waiver associated with the Car 
Class and Rate Plan for the particular Account. This area may be changed or edited. 
Each area will have a drop-down box to be able to select additional items. 

33.2 Validation 

None identified at this time. 
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33.3 Business Exceptions 

Negative values may not be entered in the rate area. If attempted, display message "Must 
specify positive amount". 

Dates may be changed, but cannot be beyond the Pick-up and/or Return date range. If 
this is attempted, display appropriate message, either "Start date cannot be before pick-up 
date" or "End date cannot be after return date". 

Similarly, Times may be changed, but cannot be beyond the Pick-up and/or Return time 
range. If this is attempted, display appropriate message, either "Start time cannot be 
before pick-up time" or "End time cannot be after return time". 

33.4 System Exceptions 

None identified at this time 

34. Coverages - PAI Area 

34.1 Behavior 

This area will initially default to the amount of Personal Accident Insurance associated with the 
Car Class and Rate Plan for the particular Account. This area may be changed or edited. 
Each area will have a drop-down box to be able to select additional items. 

34.2 Validation 

None identified at this time. 

34.3 Business Exceptions 

Negative values may not be entered in the rate area. If attempted, display message "Must 
specify positive amount". 

Dates may be changed, but cannot be beyond the Pick-up and/or Return date range. If 
this is attempted, display appropriate message, either "Start date cannot be before pick-up 
date" or "End date cannot be after return date". 

Similarly, Times may be changed, but cannot be beyond the Pick-up and/or Return time 
range. If this is attempted, display appropriate message, either "Start time cannot be 
before pick-up time" or "End time cannot be after return time". 

34.4 System Exceptions 

None identified at this time 


35. Coverages - SLP Area 

35.1 Behavior 

This area will initially default to the amount of Supplemental Liability Protection associated with 
the Car Class and Rate Plan for the particular Account. This area may be changed or edited. 
Each area will have a drop-down box to be able to select additional items. 

35.2 Validation 

None identified at this time. 
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35.3 Business Exceptions 

Negative values may not be entered in the rate area. If attempted, display message "Must 
specify positive amount". 

Dates may be changed, but cannot be beyond the Pick-up and/or Return date range. If 
this is attempted, display appropriate message, either "Start date cannot be before pick-up 
date" or "End date cannot be after return date". 

Similarly, Times may be changed, but cannot be beyond the Pick-up and/or Return time 
range. If this is attempted, display appropriate message, either "Start time cannot be 
before pick-up time" or "End time cannot be after return time". 

35.4 System Exceptions 

None identified at this time. 

36. Cancel Function Button 

36.1 Behavior 

The Cancel image/button will take the user to the last panel accessed. 

36.2 Validation 

None identified at this time. 

36.3 Business Exceptions 

None identified at this time. 

36.4 System Exceptions 

None identified at this time, 


General Requirements 

37. Error Message - Session Already Exists for this Browser Instance 

This captures the Error Message generated when the user attempts to open a new session 
on the terminal without opening a new instance of the IE browser. 

37.1 Behavior 

When the user attempts to open a new session on the same terminal without opening a 
new instance of the browser, display the following error message: 

'There is a session already open for this browser on this terminal. 
Please use that session or open a new browser." 

For Informational purposes: This situation can occur when the user attempts to open the 
active session by selecting the window titled "About" and uses the "back" button to 
navigate to the previous page. 
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38. Security 

The user must have the appropriate security level to access these screens. The user is allowed to view or 
print anything. It is when they attempt to edit a reservation that their security restrictions will be enforced. 
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Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the Vehicle / Shop screen. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 


2. Screen Prints 


Vehicle / Shop - Microsoft Internet Explorer provided by Enterprise Rent a-iar 



Figure 1 - Vehicle / Shop (North America) 
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Figure 4 - Add Account Not on File 
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3 Vehicle / Shop"- Germany - Microsoft Internet explorer provided by Enterprise Rent-a-Car 



Figure 5 - New Contact 
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3. Vehicle / Shop (Figure 1, Figure 2, Figure 3) 

3.1 Registration Number (Vehicle area of Renter's Vehicle sub-screen) 

3.1.1 Behavior 

This is a text field in which the user may enter a Registration Number. This field only 
appears on the European versions (Figure 2, Figure 3) of the application and is hidden on 
the North American version (Figure 1). 

3.1.2 Validation 

No validation is necessary. 

3. 13 Business Exceptions 

None have been identified at this time. 

3.1.4 System Exceptions 

None have been identified at this time. 

3.2 Year (Vehicle area of Renter's Vehicle sub-screen) 

3.2.1 Behavior 

This is a drop-down field containing the Years available for searching. This field is 
hidden on the Ireland and United Kingdom version (Figure 2) of the application and is 
visible on the North American and German versions (Figure 1, Figure 3). 

3.2.2 Validation 

No validation is necessary. 

3. 2. 3 Business Exceptions 

None have been identified at this time. 

3. 2. 4 System Exceptions 

None have been identified at this time. 

3.3 Class {Vehicle area of Renter's Vehicle sub-screen) 

3.3.1 Behavior 

This is a drop-down field containing a list of numbers from 1 to 10 for the User to select as the Class. 
This field only appears on the German version (Figure 3) of the application and is hidden on the North 
American and the Ireland and United Kingdom versions (Figure 1, Figure 2). 

3.3.2 Validation 

No validation is necessary. 

3. 3. 3 Business Exceptions 

None have been identified at this time. 

3.3.4 System Exceptions 

None have been identified at this time. 
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3.4 Make (Vehicle area of Renter's Vehicle sub-screen) 


3.4.1 Behavior 

This is a drop-down field containing a list of makes available for the Year (3.2) selected. 
If a Make different from "Other Make" is selected from the list, the Other Make (3.5) 
field should be cleared out. This field appears on all versions (Figure 1, Figure 2, Figure 
3) of the application. 

3.4.2 Validation 

No validation is necessary. 

3. 4. 3 Business Exceptions 

None have been identified at this time. 

3A.4 System Exceptions 

None have been identified at this time. 

3.5 Other Make (Vehicle area of Renter's Vehicle sub-screen) 

3.5.1 Behavior 

This is a text field in which the user may enter a Make that was not available in the drop- 
down. If a value is entered, the Make (3.4) drop-down field should be cleared out if it has 
a value different from "Other Make". This field appears on all versions (Figure 1, Figure 
2, Figure 3) of the application. 

3.5.2 Validation 

No validation is necessary. 

3.5.3 Business Exceptions 

None have been identified at this time. 

3.5.4 System Exceptions 

None have been identified at this time. 

3.6 Model (Vehicle area of Renter's Vehicle sub-screen) 

3.6.1 Behavior 

This is a drop-down field containing a list of models available for the Make (3.4) 
selected. If a Model different from "Other Model" is selected from the list, the Other 
Model (3.7) field should be cleared out. This field appears on all versions (Figure 1, 
Figure 2, Figure 3) of the application. 

3.6.2 Validation 

No validation is necessary. 

3. 6. 3 Business Exceptions 

None have been identified at this time. 

3. 6. 4 System Exceptions 

None have been identified at this time. 
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3.7 Other Model (Vehicle area of Renter's Vehicle sub-screen) 


3.7.1 Behavior 

This is a text field in which the user may enter a Model that was not available in the drop- 
down. If a value is entered, the Model (3.6) drop-down field should be cleared out if it 
has a value different from "Other Model". This field appears on all versions (Figure 1, 
Figure 2, Figure 3) of the application. 

3.7.2 Validation 

No validation is necessary. 

3. 7. 3 Business Exceptions 

None have been identified at this time. 

3. 7. 4 System Exceptions 

None have been identified at this time. 

3.8 Color (Vehicle area of Renter's Vehicle sub-screen) 

3.8.1 Behavior 

This is a drop-down field containing a list of available colors. If a Color different from 
"Other Color" is selected from the list, the Other Color (3.9) field should be cleared out. 
This field appears on all versions (Figure 1, Figure 2, Figure 3) of the application. 

3.8.2 Vaiidation 

No validation is necessary. 

3. ft 3 Business Exceptions 

None have been identified at this time. 

3. 8 A System Exceptions 

None have been identified at this time. 

3.9 Other Color (Vehicle area of Renter's Vehicle sub-screen) 

3.9.1 Behavior 

This is a text field in which the user may enter a Color that was not available in the drop- 
down. If a value is entered, the Color (3.8) drop-down field should be cleared out if it has 
a value different from "Other Color". This field appears on all versions (Figure 1, Figure 
2, Figure 3) of the application. 

3.9.2 Validation 

No validation is necessary. 

3. 9. 3 Business Exceptions 

None have been identified at this time. 

3.9.4 System Exceptions 

None have been identified at this time. 
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3.10 Is Car Drivable? (Loss Information area of Renter's Vehicle sub-screen) 


3.10.1 Behavior 

This is a drop down field containing the following domain values: 

• (Blank) - Default 

• Yes 

• No 

This field appears on all versions (Figure 1, Figure 2, Figure 3) of the application. 

3.10.2 Validation 

No validation is necessary. 

3.70.3 Business Exceptions 

None have been identified at this time. 

3.10.4 System Exceptions 

None have been identified at this time. 

3.1 1 Type of Loss? (Loss Information area of Renter's Vehicle sub-screen) 

3.11.1 Behavior 

This is a drop down field containing the following domain values: 

• (Blank) - Default 

• Damage 

• Theft 

This field appears on all versions (Figure 1, Figure 2, Figure 3) of the application. 

3.11.2 Validation 

No validation is necessary. 

3.11.3 Business Exceptions 

None have been identified at this time. 

3.11.4 System Exceptions 

None have been identified at this time. 

3.12 Total Loss? (Loss Information area of Renter's Vehicle sub-screen) 

3.12.1 Behavior 

This is a drop down field containing the following domain values: 

• (Blank) - Default 

• Yes 

• No 

This field appears on all versions (Figure 1, Figure 2 5 Figure 3) of the application. 

3.12.2 Validation 

No validation is necessary. 

3.12.3 Business Exceptions 

None have been identified at this time. 
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3. 12.4 System Exceptions 

None have been identified at this time. 

3.13 Date of Loss (Loss Information area of Renter's Vehicle sub-screen) 

3.13.1 Behavior 

This is a text field in which the user may enter a date value. This field appears on all 
versions (Figure 1, Figure 2, Figure 3) of the application. 

3.13.2 Validation 

Entered data should be in a MM/DD/YYYY format. 

3.13.3 Business Exceptions 

None have been identified at this time. 

3. 13.4 System Exceptions 

None have been identified at this time. 

3.14 Calendar button (Loss Information area of Renter's Vehicle sub-screen) 

3.14.1 Behavior 

This will bring up a calendar pop-up window allowing the user to select a specific date. 
The selected date will fill the Date of Loss (3.13) field. This button appears on all 
versions (Figure 1, Figure 2, Figure 3) of the application. 

3.14.2 Validation 

No validation is necessary. 

3. 14.3 Business Exceptions 

None have been identified at this time. 

3. 14. 4 System Exceptions 

None have been identified at this time. 

3.15 Theft Waiver Days (Loss Information area of Renter's Vehicle sub-screen) 

3.15.1 Behavior 

This is a drop down field containing the following domain values: 

• (Blank) - Default 

• 1 Day 

• 2 Days 

• 3 Days 

This field only appears on the North American version (Figure 1) of the application and is hidden on the 
European versions (Figure 2, Figure 3). 

3.15.2 Validation 

No validation is necessary. 

3.15.3 Business Exceptions 

None have been identified at this time. 
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3. 15.4 System Exceptions 

None have been identified at this time. 

3.1 6 Vehicle Notes (Renter's Vehicle sub-screen) 

3.16.1 Behavior 

This is a free form text field in which the user may enter data. The information entered 
here is only visible from this screen. This field appears on all versions (Figure 1, Figure 
2, Figure 3) of the application. 

3.16.2 Validation 

No validation is necessary. 

3.16.3 Business Exceptions 

None have been identified at this time. 

3.16.4 System Exceptions 

None have been identified at this time. 

3.17 Account Name (Shop sub-screen) 

3.17.1 Behavior 

This field's value is entered when: 

• User enters the Account name. 

• User clicks the "down arrow" button (3.18) to the immediate right and selects an 
Account from the Branch Short list. 

• User enters a valid number in the Account Number (3.19) field. That number's 
Account name value will then populate this field. 

• User clicks the "Search" button (3.20) and selects an Account from the Account 
Information list. 

• User clicks the "Not on File" button (3.21) and enters the appropriate new 
Account information. 

If an Account name is entered, the Account Number (3.19), Contact Name (3.22) and Phone Number (3.25) 
fields will then be populated. If the Account name is blanked out and the user tabs off or leaves the field, 
Account Number (3.19) and Contact (3.22) will also be blanked out. This field appears on all versions 
(Figure 1, Figure 2, Figure 3) of the application. 

3.17.2 Vaiidation 

No validation is necessary. 

3. 7 7. 3 Business Exceptions 

None have been identified at this time. 

3.17.4 System Exceptions 

None have been identified at this time. 
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3.1 8 Down arrow button (Shop sub-screen) 


3.18.1 Behavior 

This will bring up the Branch Short list allowing the user to select a specific Account. If 
in Europe, the European Branch Short list will be brought up. If an Account is selected, 
the Account Name (3.17), Account Number (3.19), Contact Name (3.22) and Phone 
Number (3.25) fields will then be populated. This button appears on all versions (Figure 
1, Figure 2, Figure 3) of the application. 

3.18.2 Validation 

No validation is necessary. 

3.18.3 Business Exceptions 

None have been identified at this time. 

3.18.4 System Exceptions 

None have been identified at this time. 

3.19 Account Number (Shop sub-screen) 

3.19.1 Behavior 

This field's value is entered when: 

• User enters a valid name in the Account Name (3.17) field. That name's Account 
number value will then populate this field. 

• User clicks the "down arrow" button (3.18) to the immediate left and selects an 
Account from the Branch Short list. 

• User enters the Account number. 

• User clicks the "Search" button (3.20) and selects an Account from the Account 
Information list. 

• User clicks the "Not on File" button (3.21) and enters the appropriate new 
Account information. 

If an Account number is entered, the Account Name (3.17), Contact Name (3.22) and Phone Number (3.25) 
fields will then be populated. If the Account number is blanked out and the user tabs off or leaves the field, 
Account Name (3.17) and Contact (3.22) will also be blanked out. This field appears on all versions (Figure 
1, Figure 2, Figure 3) of the application. 

3.19.2 Validation 

No validation is necessary. 

3.19.3 Business Exceptions 

None have been identified at this time. 

3.19.4 System Exceptions 

None have been identified at this time. 

3.20 Search button (Shop sub-screen) 

3.20.1 Behavior 

This will bring up the Account Search screen allowing the user to search for and then 
select a specific Account. If an Account is selected, the Account Name (3.17), Account 

Confidential ©Enterprise Rent-A-Car, Page 17 

2001 


Rental Redesign 

Version: 2.7 

Screen Action Specification 

Date: 12/20/2001 

Vehicle / Shop 


Number (3.19), Contact Name (3.22) and Phone Number (3.25) fields will then be 
populated. This button appears on all versions (Figure 1, Figure 2, Figure 3) of the 
application. 


3.20.2 Validation 

No validation is necessary. 

3.20.3 Business Exceptions 

None have been identified at this time. 

3.20.4 System Exceptions 

None have been identified at this time. 

3.21 Not on File button (Shop sub-screen) 

3.21.1 Behavior 

This will bring up the Add Account Not on File screen (Figure 4) allowing the user to 
enter information for a new Account. After all the necessary fields on that screen are 
entered, the Account Name (3.17), Account Number (3.19), Contact Name (3.22) and 
Phone Number (3.25) fields will then be populated with that screen's entered 
information. This button appears on all versions (Figure 1, Figure 2, Figure 3) of the 
application. 

3.21.2 Validation 

No validation is necessary. 

3.213 Business Exceptions 

None have been identified at this time. 

3.21 A System Exceptions 

None have been identified at this time. 

3.22 Contact Name (Shop sub-screen) 

3.22.1 Behavior 

This field's value is entered when: 

• User enters a valid name in the Account Name (3.17) field. That name's Contact 
name value will then populate this field. 

• User clicks the "down arrow" button (3.18) to the immediate right of Account 
Name (3.17) and selects an Account from the Branch Short list. That Account's 
Contact name value will then populate this field's value. 

• User enters a valid number in the Account Number (3.19) field. That number's 
Contact name value will then populate this field. 

• User clicks the "Search" button (3.20) and selects an Account from the Account 
Information list. That Account's Contact name value will then populate this 
field's value. 

• User clicks the "Not on File" button (3.21) and enters the appropriate new Contact 
information after the new Account information. After all the necessary fields on 
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that screen are entered, that screen's entered information for Contact name will 
then populate this field's value. 

• User enters the Contact name. 

• User clicks the "down arrow" button (3.23) to the immediate right and selects a 
Contact from the Contact list. 

• User clicks the "Add New" button (3.24) and enters the appropriate new Contact 
information. 

This field appears on all versions (Figure 1, Figure 2, Figure 3) of the application. 

3.22.2 Validation 

No validation is necessary. 

3.22.3 Business Exceptions 

None have been identified at this time. 

3. 22. 4 System Exceptions 

None have been identified at this time. 

3.23 Down arrow button (Shop sub-screen) 

3.23.1 Behavior 

This will bring up the Contact list allowing the user to select a specific Contact. If a 
Contact is selected, the Contact Name (3.22) field will then be populated. This button 
appears on all versions (Figure 1, Figure 2, Figure 3) of the application. 

3.23.2 Validation 

No validation is necessary. 

3.23.3 Business Exceptions 

None have been identified at this time. 

3.23.4 System Exceptions 

None have been identified at this time. 

3.24 New Contact button (Shop sub-screen) 

3.24.1 Behavior 

This will bring up the New Contact screen (Figure 5) allowing the user to enter 
information for a new Contact. 

After the necessary field(s) on that screen is/are entered, the Contact Name (3.22) field 
will then be populated with that screen's entered information. This button appears on all 
versions (Figure 1, Figure 2, Figure 3) of the application. 

3.24.2 Validation 

No validation is necessary. 

3. 24. 3 Business Exceptions 

None have been identified at this time. 

3.24A System Exceptions 

None have been identified at this time. 
Confidential ©Enterprise Rent- A-Car, Page 1 9 

2001 


Rental Redesign 

Version: 2.7 

Screen Action Specification 

Date: 12/20/2001 

Vehicle / Shop 


3.25 Phone Number (Shop sub-screen) 

3.25.1 Behavior 

This field's value is entered when: 

• User enters a valid name in the Account Name (3,17) field. That name's Phone 
number value will then populate this field. 

• User clicks the "down arrow" button (3.18) to the immediate right of Account 
Name (3.17) and selects an Account from the Branch Short list. That Account's 
Phone number value will then populate this field's value. 

• User enters a valid number in the Account Number (3.19) field. That number's 
Phone number value will then populate this field. 

• User clicks the "Search" button (3.20) and selects an Account from the Account 
Information list. That Account's Phone number value will then populate this 
field's value. 

• User clicks the "Not on File" button (3.21) and enters the appropriate new 
Account information. That Account's Phone number value will then populate this 
field's value. 

• User enters the Phone number. 

This button appears on all versions (Figure 1, Figure 2, Figure 3) of the application. 

3.25.2 Validation 

No validation is necessary. 

3.25.3 Business Exceptions 

None have been identified at this time. 

3. 25. 4 System Exceptions 

None have been identified at this time. 

3.26 Button Line Area 

3.26.1 Behavior 

The Previous button will take the user to the Bill-to screen within the same transaction. 

The Next button will take the user to the Notes screen within the same transaction. 

The Complete button will initiate a save of the transaction. All validations will be 
performed, returning any errors to the user. If there are no errors, the transaction is 
saved, and the user is returned to the Open Ticket home page. 

4. Not on File (Figure 4) 

4.1 Name 

4.1.1 Behavior 

This is a text field in which the user may enter an Account name. 
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4.1.2 Validation 

No validation is necessary. 

4.1.3 Business Exceptions 

None have been identified at this time. 

4. 1.4 System Exceptions 

None have been identified at this time. 

4.2 Address 

4.2.1 Behavior 

This is a free form text field in which the user may enter an Account's address. 

4.2.2 Validation 

No validation is necessary. 

4. 2. 3 Business Exceptions 

None have been identified at this time. 

4. 2. 4 System Exceptions 

None have been identified at this time. 

4.3 Zip 

4.3.1 Behavior 

This is a text field in which the user may enter an Account's zip code. 

4.3.2 Validation 

No validation is necessary. 

4. 3. 3 Business Exceptions 

None have been identified at this time. 

4.3.4 System Exceptions 

None have been identified at this time. 

4.4 Geographic Framework button (lightening bolt graphic) 

4.4.1 Behavior 

This will fill in the City (4.6) and State (4.7) fields if there is only 1 city for the zip code. 
If more than 1 city is in the entered zip code, the Multiple Cities Found page will be 
brought up, allowing the user to select a city. The City (4.6) and State (4.7) fields will 
then be filled with the user's selection. 

4 A. 2 Vaiidation 

No validation is necessary. 

4.4.3 Business Exceptions 

None have been identified at this time. 

4.4.4 System Exceptions 

None have been identified at this time. 
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4.5 Country 

4.5.1 Behavior 

This is a drop down field containing the list of countries. 

4.5.2 Validation 

No validation is necessary. 

4. 5. 3 Business Exceptions 

None have been identified at this time. 

4. 5. 4 System Exceptions 

None have been identified at this time. 

4.6 City 

4.6.1 Behavior 

This is a text field in which the user may enter an Account's city. This field may also be 
filled by actions performed by the Geographic Framework button (4.4). 

4.6.2 Validation 

No validation is necessary. 

4. 6. 3 Business Exceptions 

None have been identified at this time. 

4.6.4 System Exceptions 

None have been identified at this time. 

4.7 State 

4.7.1 Behavior 

This is a drop down field containing the list of states. This field may also be filled by 
actions performed by the Geographic Framework button (4.4). 

4.7.2 Validation 

No validation is necessary. 

4. 7. 3 Business Exceptions 

None have been identified at this time. 

4.7.4 System Exceptions 

None have been identified at this time. 

4.8 Phone 

4.8.1 Behavior 

This is a text field in which the user may enter an Account's phone number. 

4.8.2 Validation 

Entered data should be 10 digits for the US to include area code or the appropriate format 
for other countries. 
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4.8.3 Business Exceptions 

None have been identified at this time. 

4. 8. 4 System Exceptions 

None have been identified at this time. 

4.9 Contact Last Name 


4.9.1 Behavior 

This is a text field in which the user may enter a Contact's last name for the new 
Account. 

4.9.2 Validation 

No validation is necessary. 

4. 9. 3 Business Exceptions 

None have been identified at this time. 

4.9.4 System Exceptions 

None have been identified at this time. 

4.1 0 Contact First Name 

4.10.1 Behavior 

This is a text field in which the user may enter a Contact's first name for the new 
Account. 

4.10.2 Validation 

No validation is necessary. 

4. 10. 3 Business Exceptions 

None have been identified at this time. 

4.10.4 System Exceptions 

None have been identified at this time. 

4.1 1 Button Line Area - Add Account Not on File 

4.11.1 OK button 

4.11.1.1 Behavior 

If data is not present in the required fields the feedback message explains that a value 
needs to be entered in the field(s) that is/are blank. Two options are presented, OK and 
Cancel. OK takes the user back to the Add Account Not on File screen for data entry; 
Cancel dismisses the Add Account Not on File screen. 
OK will be the default selection. 

4.11.1.2 Validation 

There must be data present in all fields except for Contact Last Name (4.9) and First 
Name (4.10) where only one needs to have data present. 
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4.1 1 .1 .3 Business Exceptions 

None have been identified at this time. 

4.1 1 .1 .4 System Exceptions 

None have been identified at this time. 

4.11.2 Cancel button 


4.11.2.1 Behavior 

This button will dismiss the Add Account Not on File screen without saving any data. 

4.11.2.2 Validation 

If data has been entered the following feedback message is displayed; "Are you sure you 
want to exit and lose the entered information?" Two options are presented, Yes and No. 
Yes will dismiss the screen and not save the data, No will take the user back to the Add 
Account Not on File screen. 
The default button selection is "No". 

4.11.2.3 Business Exceptions 

None have been identified at this time. 

4.11.2.4 System Exceptions 

None have been identified at this time. 

5. New Contact (Figure 5) 

5.1 Last Name 

5.1.1 Behavior 

This is a text field in which the user may enter a Contact's last name for an already 
selected Account. 

5.1.2 Validation 

No validation is necessary. 

5.1.3 Business Exceptions 

None have been identified at this time. 

5.1.4 System Exceptions 

None have been identified at this time. 

5.2 First Name 

5.2.1 Behavior 

This is a text field in which the user may enter a Contact's first name for an already 
selected Account. 

5.2.2 Validation 

No validation is necessary. 

5. 2. 3 Business Exceptions 

None have been identified at this time. 
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5. 2. 4 System Exceptions 

None have been identified at this time. 

5.3 Button Line Area - Add Contact 

5.3.1 OK button 

5.3.1.1 Behavior 

If data is not present in the Last Name (5.1) and/or the First Name (5.2) field(s), the 
feedback message explains that a value needs to be entered for Last Name (5.1) and/or 
First Name (5.2). Two options are presented, OK and Cancel. OK takes the user back to 
the Add Contact screen for data entry, Cancel dismisses the Add Contact screen. 
OK will be the default selection. 

5.3.1.2 Validation 

There must be data present in the Last Name (5.1) and/or First Name (5.2) field(s). 

5.3.1.3 Business Exceptions 

None have been identified at this time. 

5.3.1.4 System Exceptions 

None have been identified at this time. 

5.3.2 Cancel button 

5.3.2.1 Behavior 

This button will dismiss the Add Contact screen without saving any data. 

5.3.2.2 Validation 

If data has been entered the following feedback message is displayed; "Are you sure you 
want to exit and lose the entered information?" Two options are presented, Yes and No. 
Yes will dismiss the screen and not save the data, No will take the user back to the Add 
Contact screen. 

The default button selection is "No". 

5.3.2.3 Business Exceptions 

None have been identified at this time. 

5.3.2.4 System Exceptions 

None have been identified at this time. 

6. Rules 

6.1 Year, Make and Model domain values come from the database. 

6.2 A Contact must be selected for every Account that is selected as a Shop. 

6.3 The system should not search for or display any deactivated Accounts. 

6.4 User needs to have ability to cancel a search at any time during the search. 
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6.5 Notes should be generated when any of the following events occur: 


User adds a 
"Not on File" 
Shop 

Shop [Blank] was changed to 
"XXXX" 

Creat 
e/Edit 

Create (if data exists 
from the reservation) 
/Edit 

Vehicle/Sh 
op 

User adds a 
"Not on File" 
Shop Contact 

Not on File Contact "First Name Last 
Name" was added for Account 
"XXXXX" 

Creat 
e/Edit 

Create (if data exists 
from the reservation) 
/Edit 

Vehicle/Sh 
op 

User changes 
the Shop 
Account 

Shop "XXXX" was changed to 
"XXXX" 

Edit 

Create (if data exists 
from the reservation) 
/Edit 

Vehicle/Sh 
op 

User changes 
the Type of 
Loss 

Type of Loss "XXXX" was changed 
to "XXXX" 

Edit 

Create (if data exists 
from the reservation) 
/Edit 

Vehicle/Sh 
op 

User changes 
the "Total 
Loss?" 

Total Loss "XXXX" was changed to 
"XXXX". 

Edit 

Create (if data exists 
from the reservation) 
/Edit 

Vehicle/Sh 
op 

User changes 
the Date of 
Loss 

Date of Loss "XXXXXX" was 
changed to "XXXXXX" 

Edit 

Create (if data exists 
from the reservation) 
/Edit 

Vehicle/Sh 
op 

User changes 
number of 
Theft Waiver 
Days 

Theft Waiver Days "X" was changed 
to "X" 

Edit 

Create (if data exists 
from the reservation) 
/Edit 

Vehicle/Sh 
op (North 
America) 

User changes 
the 

Registration 
Number 

Registration Number "XXXX" was 
changed to "XXXX" 

Edit 

Edit 

Vehicle/Sh 
op (Ireland, 

UK, 
Germany) 

User changes 

tbe f^la^ 

Class "XX" was changed to "XX" 

Edit 

Edit 

Vehicle/Sh 
op 

(Germany) 

User changes 
the Renter's 

Vphir1e\ Year 

The Renter's Vehicle Year "XXXX" 
was changed to Year "XXXX" 

Edit 

Edit 

Vehicle/Sh 
op 

User changes 
the Renter's 

V cmt/lc i> 

Make 

The Renter's Vehicle Make "XXXX" 
was changed to Make "XXXX" 

Edit 

Edit 

Vehicle/Sh 
op 

User changes 
the Renter's 
Vehicle's 
Model 

The Renter's Vehicle Model 
"XXXX" was changed to Model 
"XXXX" 

Edit 

Edit 

Vehicle/Sh 
op 

User changes 
the Renter's 

The Renter's Vehicle Other Make 
"XXXX" was changed to "XXXX" 

Edit 

Edit 

Vehicle/Sh 
op 
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Vehicle Other 
Make text 





User changes 
the Renter's 
Vehicle Other 
Model text 

The Renter's Vehicle Other Model 
"XXXX" was changed to "XXXX" 

Edit 

Edit 

Vehicle/Sh 
op 


7. Security 

A user is authorized through a login process to create or edit a reservation or ticket. 
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Use Case Specification: Bill-to 

1. Bill-to 

1.1 Brief Description 

This use case describes the "Bill-to process" within the context of the ticket or the reservation. The "Bill-to 
process" is limited here to adding and deleting an account number as a Bill-to, and adding, changing, 
extending and deleting an authorization. 

This use case will encompass all of Ihe requirements that are relevant from ECARS 1.0 as well as those 
from VRS which are deemed part of the 1 st phase of ECARS 2.0. This use case only pertains to non- 
ARMS transactions. 
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2. Flow of Events 


2.1 Basic Flow 

2.1.1 Add a Bill-to 

2.1.1.1 The user navigates, within the Ticket or the Reservation, to the Bill-to area. 

2.1.1.2 The system allows the user to indicate who will be billed^ 

2.1.1.3 The user can search for an account by name or s/he can enter the account number djrectjy. 

2.1.1.4 If the user elects to search for the account, the system will first provide a list of the accounts 
already in use on the ticket or reservation (if applicable) and provide a list of the branch's most 
commonly used accounts, as determined by the criteria in the branch description in TX01 . Ifthe 
user elects to use an account not in this list, they can search across all of the accounts on file . 

2.1.1 .5 If there is no account in the system for the intended bill-to, see alternative flow: Account not on 
file. If the user elects to enter the account number without search, the system must validatethe 
account before proceeding . ~~ 

2.1.1.6 The user selects a contact . If the contact is not found, the user elects to add one and entersjhe 
contact's full name, phone'number and phone number. Either the first name or last name is 
required. This Is saved on the ticket / reservation, a s well as b eing added as a contact forthe 
account. 

2.1.1.7 The user must select an authorization status. 

2.1.1.8 System logs the detail s in the "Notes^ 

2.1.1.9 Use Case Ends 

2.2 Alternative Flows 
2.2.1 Remove a Bill-to 

2.2.1.1 The user navigates, within the Ticket or the Reservation , to the Bill -to area. 

2.2.1.2 The user indicates that s/he wishes to remove a Bill-to. 

2.2.1.3 The user selects the Bill-to account number which s/he wishes to remove from among the bill-tos 
on the ticket or reservation. Anybili-to on the ticket which has at least one ARMS authorization 
associated to it cannot IjeTemoved and therefore shouldn't be presented to the user as an 
option. 

2.2.1.4 The system displays to the user all of the details of any authorizations associated will the Bill-to 
for that ticket or reservation along with the option to cancel their choiceT ~ 

2.2.1.5 User elects to continue. If they elect to cancel, the use caseends . 

2.2.1.6 The system removes the bill-to from the ticket or reservation as well as any authorizations and all 
required billing information associated to the bill-to and logs the details in the "Notes". 

2.2.1.7 If there are other Bill-tos on the ticket or reservation, and they a re a higher number bill-to, then 
they will be changed to a lower number. (For^example, if Bill-to One is Smith Insurance anpgjll^ 
toTwo isBrow n Auto Bo dy, and the user removes Smith Ins urance fro m the reservation/ticket, ~~ 
then Brown Auto Body becomes Bill-to Qne.[ 
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2.2.1 .8 The use case ends. 


2.2.2 Add authorization details 

The user navigates, within the Ticket or the Reservation, to the Bill-to area . 

The user indicates that s/he wishes to add an authorization. 

The system presents the user with the following fields: 

Authorization gMj§J^^gp^dJE^dmg ^^^^^^k^^SS^J^^^^ 
Reim bursed/ Fen ding OiU at Open) 

Daily amount of authorization 

ItemXs),authprized 

Be^maiog date, arid time authorized 

Ending date and time wjhqr jzed 

Person from the jbtiU-tp organiz^jfo^ 
Maximum amount of autiiorization 
Maximum number of days„of_^thrjrjzation 

Flat a_mou_nt „9i ^QJE^tion 
" All charges" authorjgation 
Iryformafo 

f ields for the L,Clairn/ PQ/ RO a nd jnsured jjame fields) . 
\y t In order to add an authorization, the user must change the authorization status to "Authorized" and enter the 

~; required information, as detennined by thesituation. (See add daily authorization add authorization ~ 

n\ maximums, flat authorization, last day and required information for the detai ls.) 

y * — = = 

f I The system automatically enters the details of the authorization into the reservation or ticket notes detailing 

jjsb the Enterprise employee who performed the authorization as well as all of the associated details. 

The use case ends. 

2.2.2.1 Add daily authorization 

The user indicates that s/he wishes to add a daily authorization. 

User indicates the following: 


u 

US 

PI 


The ampunt rjgr. day .tjhat Js authori zed. 

The item or i tems to which LitoUffl^t^^fegJE^4 

Whether 

to the authorization. 

The.,date..tbe^ 
required r These 

date and .time of jfeexeseryation (ilamUableJ, 

The end date jjQhe ; auAo^r^ation If the number 

pf daysjsjr^ IL%24.hpJir MMgMfl^ 

then jfrg \Jome i5_^o.jgg3}ted[. 
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Thename.pf ^ 

2.2.2.2 Add authorization maximums 

The user indicates that s/he wishes to add an authorization maximum. 

User indicates the following: 


The maximum amount t hat the Lbiff-to^n b^d> the maximum nu mber of days that they 
m&]9f^^^.iiM^i • Ifthe ^indicateb^^ 

The name of the perso n from the b ill-to account who set the maximum. 

NOTE: The maxjmumjm^^ to mdicate an 

amount ±,tax / ,etc^ 

2.2.2.3 Last Day 

User indicates the following: 

The date beyond _which i no ^charges may be ^pp)i^Joj^PPkP. • If „thg ticket or reservation 

The name of the person from the bill-to account who se t the final date, 
2.2.3 Change Authorization Amount 

2.2.3.1 This allows the user to change an authorization which has already been entered. 

2.2.3.2 The user navigates, within the Ticket or the Reservation, to the Bill-to area. 

2.2.3.3 The user ind icates that s/he wishes to change the amount of an authorization for Bill-to. 

2.2.3.4 If the user wants to change an existing amount for dates which have already been au^Qtjgg^ 
s/he indicates the authorization that s/he wishes to change and chang esit Because ARMS^ " 
authorizations cannot be changed b y the user, t he system should not maRe any ARMS 
authorizations available to themT 

2.2.3.5 The system automatically enters the details of the authorization into the reservation or ticket 
notes detailing the Enterprise employee who performed the a uthorizatio n as well as all of the 
associated details. 

The use case ends. 

Extend Authorization 

The user navigates, within the Ticket or the Reservation, to the Bill-to_area 1 

The user indicates that s/he wishes to extend an authoriza tion for a s pecific Bill-ta The user 
shouldnot have any authorizations available to them which are ARMS authorizations^ 

2.2.4.3 The system presents the user with the end date of the most recent authorization amount and 
allows them to changeTE " 

2.2.4.4 If the user wishes to change the authorization amount, go to the Change Authorization alternative 
flow. 

2.2.4.5 The user changes the end date to a date later than the date already in the authorization. If they 
enteradate which is the same as the date already entered, then the use case_ends 1 

2.2.4.6 If the user attempts to change an end date for an authorization which has been "Last Dayed^ 
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then the system presents the user with an informational message and asks them to confirmjthe 
cFiange. If they confirm, then the Last Da y Date is up dated accordingly. The authorization status 
remains "TerminatecTT 

2.2.4.7 The system automatically enters the details of the authorization into the reservation or ticket 
n otes detailing the Enterprise employee who performed the authorization as well as ali ofthe 
associated details. 

2.2.4.8 The use case ends. 

2.2.5 "Last Day" authorization 

2.2.5.1 The user navigates, within the Ticket or Reservation, to the Bill-to area. 

2.2.5.2 The system provides the option to indicate that the end date of the authorization is final and 
cannot be changed. Ifthe authorization is an ARMS authorization, this option is not available 
and the use case endsT 

2.2.5.3 The user elects to make the end date ofthe authorization the LAST DAY. 

2.2.5.4 The system automatically changes the authorization status t o 'Terminat ed" and enters the details 
of the authoriza tion into th e reservation or ticket notes detailing the Enterprise employee who ~ 
performed the LAST DAY authorization as well as all of the associate d details. 

2.2.5.5 The use case ends. 

2.2.6 Remove Authorization 

2.2.6.1 The user navigates, within the Ticket or Reservation, to the Bill-to area. 

2.2.6.2 The user indicates that s/he wishes to remove a single a uthorizati on for a specific Bill-to If the 
authorization is an ARMS authorization, this option is not available and the use case ends. 

2.2.6.3 The system presents an option to the user to cancel their choice, along w ith all ofth e details of 
the authorization they selected. The details include which item(s) the authorization applies to and 
the amount and dates coveredT 

2.2.6.4 User elects to continue. If they elect to cancel, the use case ends. 

2.2.6.5 I f the author ization the y selected to remove is the only one on the tic ket or reservation for tha^ 
Bill-to, then the system requires changes the authorization status to "Declined" but allows the 
user to change the authorization statu s to "Pending*: 

2.2.6.6 The system automatically enters the details ofthe authorization removal into the reservation Q£ 
ticket notes detailing the Enterprise employee who performed the authorization as well as all of 
the associated details? 

2.2.6.7 The use case ends. 

2.2.7 Remove all authorizations for a Bili-to Account 

2.2.7.1 The user navigates, within the Ticket or Reservation, to the Bill-to area. 

2.2.7.2 The user indicates that s/he wishes to remove all authorizations for a specific Bill-to by changing 
the authorization status to "Declined" . If the authorization is an ARMS a uthorizatio n, this option " 
is not available and the use case ends. 

2.2.7.3 The system presents an option to the user to cancel their choice, along with all of the details of 
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the authorizations. The details include which item(s) th e authorizations apply to and the amounts 
and dates covered. 


2.2.7.4 User elects to continue. If they elect to cancel, the use caseend^ 

2.2.7.5 The system automatically enters the details into the reservation or ticket notes detailjr^Jhg^ 
Enterprise employee who performed the authorization as well as all of the associated details^ 

2.2.7.6 The use case ends. 

2.2.8 Account not on file 

2.2.8.1 The user navigates, within the Ticket or Reservation, to the Bill-to area 

2.2.8.2 The user indicates that s/he wishes to bill an account whic h is not in t he system. 

2.2.8.3 The system presents fields to enter the name of the account the billing a ddress information 
pRone number and name of a contact for that accou nt. Ajlotjtie informati on is requirecL The 
address entry should follow the syste m standards which allow for the us er to enter the zip code 
and addressand have the system search for the appropriate city and state. If many city, state 
combinations are valid , the user should be allowed to se lect from them. 

2.2.8.4 The user co mpletes all of the information. If they omit any part of the inform ation and try to 
continue, the system provides a feedback message indicatin g which information is missing. The 
system allows the user to update those itemsT 

2.2.8.5 The system does not add this account to the account database. 

2.2.8.6 The system automatically enters the details of the additi on of the " Not on file" account intothe 
reservation or t icket notes detailing the Enterprise employee wh o performe d the action as well as 
all of the associated details. 

2.2.8.7 The use case ends. 

2.2.9 Adding Req uired Billing Information 

2.2.9.1 The user navigates, within the Ticket or Reservation, to the Bill-to area. 

2.2.9.2 The user indicates that s/he wishes to add "Required Billing Information" 

2.2.9.3 The user in dicates th e account for which they want to add or update the information. Any 
information associated with bill-tos on the ticket which have at least one ARMS authorization 
associated to it cannot be ch anged and t herefore, those accounts shouldn't be available toThe 
user. 

2.2.9.4 The system makes the Claim/PO/RO and the Insured Name fields available for edit. 

2.2.9.5 If the account has listed at least one of these fields as required and/or that specific fo rmatting is 
necessary, then the system indicates which f ield(s) is r equired and/or the format that the 
information must be in (if specified). 

2.2.9.6 The user enters as much information as is available. (The information isn't required until the 
ticket is closed.) ~~ 

2.2.9.7 The system automatically enters the details of the information, into the reservation or ticket notes 
detailing the Enterprise employee who performed the edit as well as all ot the associated details. 

2.2.9.8 The use case ends. 
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3. Special Requirements - Bill-to 

3.1 Number of users 

Only one user should be allowed to update authorization information on a ticket or 
reservation at a time. 

Only one user should be allowed to add or remove bill-to account numbers on a ticket or 
reservation at a time% 

3.2 Callbacks 

Anv update to authoriz ations should be taken into account bv the callbacks engine in 
generating callbacks to renters an d Bill-tos. 

3.3 Help 

If hel p text will be made available to the users, som e ex planat ion of why ARMS-authorized 
bill-tos are treated differently will be necessary, 

3.4 Authorizati on by car class 

When the user is addin g an authorization amo unt, thev must be allowed to look up the 
amount usin g a car class. F urthermore, if the retrieved rate is tiered, then the user must have 
the option either to select one of the rates or to indicate that the authorization is tiered and 
thereby associate all of the rates to the authorization. 

3.5 ARMS authorization 

Only one ARM S authorized account can be on a ticket /reservation at a time. 

Tf a bill-to account receives an ARMS authorization and it is not in the bill-to ONE position, it 
must be chan ged to bill-to one and the other bill-tos must follow it . Therefore, if bill-to one 
is Joe's Body Shop (non-AMRS) and bill-to two is Allstate (ARMS) and Allstate sends an 
initial ARMS authorization, it becomes bill-to one and Joe's Body Shop becomes bill-to two. 

4. Pre-Conditions 
4.1 User logged In 

The user must be logged in to the reservation or ticket system. 

5. Post-Conditions 

5.1 None 

6. Extension Points 
6.1 None 

7. Questions 

7.1 Rate source 

How is adding a bill-to (or removing one) expected to impact the reservation or ticket's rate source? If no 
impact, should a message be provided to the user? 

7.2 European requirements 

European requirements still need to be documented. When will these be available? 
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7.3 ARMS 

Can the user change any Bill-to information on an ARMS ticket? 


7.4 System generated notes 

What details should be included in each note? 

7.5 Name of authorizer 

Should this name be free-form text or should a list of contacts for the account be used? If a list is optimal, 
then do omit the contact for "Not on File" bill-tos? 
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from Rental Information Area. 

4. Removed "Other Items Received" 
from Rental Information Area. 

5. Added Employee Number/password 
authorization in the basic and 
alternate flows. 

6. Renter information entered or 
changed in this form makes 
changes to the corresponding renter 
or additional driver information. 

7. Added Supervisor's Phone Number 
I to the Rental Personal Information 

Area. 

David Beebe 

06/07/2001 

1.4 

Revisions based upon feedback from 
Reservation team. 

1 . Combined Personal and Rental 
Information Areas into one. 

2. Removed the following fields: First 
Name, Last Name, Social Security 

! Number, Date of Birth, Street 

I Address, Zip/Postal Code, Country, 
City, State/Province, Other 
Ownership, Home Phone Number, 

| Work Phone Number, Other Phone 
Number (and phone type), 
Previous Address #1 and #2, 
Previous Employment Information, 
Spouse Employment Information, 

j Credit Check Information. 

David Beebe 
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3. Also removed the corresponding 
Alternate Flows: No Match to 
Zip/Postal Code, Multiple City 
Results, Missing Name Information 
and Invalid Characters. 

4. Added the following fields: 
Insurance Company Name, Agent's 
Name, Agent's Phone Number and 
Policy Number. s 

5. Password and Employee Name is 
only required when entering Cash 
Qualification Information during the 
Ticket process. 

6. Take out Supervisor's Phone 
Number. (Todd Shylanski 6/13/01) 


{ 06/21/2001 

r 

:? 

i- 
Z 
? 

1.5 

1. Removed the following fields: 

Insurance Company Name, Agent's 
Name, Agent's Phone Number and 
Policy Number 

2. Added (Blank) as an option for the 
following fields: 

Ownership 

Rented Previously 

Do You Own a Car? 

David Beebe 
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Use Case Specification: Enter Cash Qualification 

Information 

1- Enter Cash Qualification loforiiiMMll§i^lgg 


1.1 Brief Description 

This use case will describe how the user and the system interact to input cash qualification 
information concerning renters and/or additional drivers, it will show the flow of events that 
occur when information is input and/or selected in this area. 


2. Flow of Events 

2.1 Basic How 

2. 1. 1 Cash Qualification Information Area 

The Enter Cas h Qualification Information Use Case begins whe n the system displays the area 
foFinti^anJsei ection of info rmation about the person being cash qualified and the rental. The 
fields in this area are: 

• How Long at the curr ent address: 
o Years 

o Months 

• Ownership : 
o (Blank) 
c Own 

c Rent 


« Current Employer 

• Pos ^ ion 

• Superviso r's Name 

• Sooke to Whom 

« How Long a t Current Job: 
c Years 
o Months 

« Reason for Renting 
o Car In Shop 
c Weekend 
o Vacation 
o Other 

o Other Reason Field 

• Previously Rented: 

o (Blank) 

o Yes 

c No 

o If So, When? 
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« Do You Own a Car?: 

o (Blank) 
o Yes 
o Ng 

* Reference #1 

o First Name 

o Last Name 

o Phone Number 

o Relationship 

* Reference #2 

c First Name 

o Last Name 

o Phone Num ber 

o Relationship 

* Reference #3 

o first Name 

o Last Name 

o Phone Number 

o Relationship 

* Password 

@ EniDlovee Number 

There are no default values for any of the above fields. 

2.1.2 Option to Cancel 

The system displays the option for the user to cancel/exit . At_apy point durin g the entry of cash 
Qualification in formation th e user could decide to can cel out of the entry proc ess at whichjime 
the use case would continue at alternate fj^QMl^MLE^L ~ 

2.1.3 Option to Save 

The system displays the option to Save. At any point during the entry of cash qualification 
Information the user coulddecide to Save, at which time the use case" would continue at basic 
flow Sav|T~ 

2.1.4 Address and Ownership Information Selection 

The user can select how long the person being cash qualified has lived at the current address. 
The user can also select whether the person being cash qualified owns or rents. 
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2.1.5 Employment Information Entry and Selection 

• The user can enter the employment information about the person being 
cash qualified. They can enter the employer, the supervisor's name, the 
person being cash qualified employment position and whom the user spoke 
to when verifying. 

• The user can also select how long the person being cash qualified has been 
employed at their current job. 


2.1.6 Rental Information Entry/Selection 

• The user can select one or more reason(s) for renting. If the user selects the "other" option, 
the field for entry of information becomes available for entry. The user then enters the 
reason. 

• The user can select whether the person being cash qualified has rented before. If the user 
selects "Yes", the field for entry of information about when they last rented becomes 
available. The user then enters when the last rental was. (See Special Requirements for 
note.) 

• The user can select whether the person being cash qualified owns a car. 

• The user can enter the insurance company name, agent's name, agent's phone number 
and the policy number information about the person being cash qualified. 


2.1.7 References Information Entry 

For all three references listed, the user can enter the First Name, Last Name, Phone Number 
and Relationship. 


2. 1.8 "Approved by:" Employee Number and Password Entry 

The user enters the Employee Number and password that approved the cash qualification. 

2.1.9 Select Save Option 

The user selects the option to Save. 

2.1.10 Validation of Employee Number and Password 

The system validates the Employee ^^^^ s ^^ ; ^^^^^^ ! M:^^ 
qUijlcitEB. If the user entered an invalid employee number and password combination the 
use case continues at alternate flow Invalid Employee Number and Password Combina tion. If 
the user entered an employee number and password that does not pass authority check the 
use case continues at alternate flow Authority Check Failed . 


2.1.11 Save 

The sys tem saves all the inform^ fields of the Cash Qualification, 

The saveFinformation would include the following: 

* How Long at the currerrt jdgi^|i 
c Years 
o Months 
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• Ownership: 
o ?BfaTTk) 
o Own 

o Rent 

• Current Employer 

• Position 
Superviso rs Name 

• Spoke to Whom 

• How LemTat CurrentJob: 
o Years " 

o Months 

® ^ eason fo f Rgptjng 

o Car In Sho p 
o Weekend 
c Vacation ' 
c Other 

o Other Reason Fie ld 

• Previously Rented: 

o Yes 
o Mg 

o If So, When? 

• DoYou Own a Car?: 
o (Blank) 

o Yj| 

c Hg 

• Reference #1 

o Fjrst^Name 

o Last Name 

o Phone Number 

o Relationship 

• Reference #2 
o First Name 
o Last Name 

c Phone Num ber 
o Relationship 

• ^ e I erence #3 
o First Name 
o Last Name 
o Phonel^^ 
o Relationship 

• The employee who selected to save the cash qualification information. 
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2.1.12 End 

The Use Case ends. 


2.2 Alternative Flows 


2.2.1 Cancel/ Exit 

2.2.1 .1 The user selects the option to cancel/exit. 

2.2.1.2 The system displays a feedback messag e warning that thejpash qualification data will be lost if 
the user selects to cancet/exit. 

2.2. 1 .3 The system displays the following options: 
® Yes: to exit and lose d ata, 

• No r 7eturn to the cash qualification use case 

{ The default option will be No; r^yjiTtocash qualification.) 

2.2.1 .4 The user selects Yes the use case ends, ff the user selects No then continue in basic flow at 
the point where the user selected to cancel/exit. 

2.2.2 Invalid Employee Number and PasswordCombination 

2.2.2.1 The system displays a feedback message that the entered Employee Number and password is 
invalid. 

2.2.2.2 The system prompts t he u ser to enter a valid Employee Number/password. 

2.2.2.3 The user selects to enter a valid Employee Number/password and returns to "Approved by" 
Employee Number and Password Entry . 

2.2.3 Authority Check Failed 

2.2.3.1 The system displays a feedback message that the employee is not allowed to autho rize cash 
qualification. * ~ ~~ — — — — - 

2.2.3.2 The system prompts the user to ent^j^alid^Employee Number/password, 

2.2.3.3 The user selects to enter a valid Employee Number/password and returns to "Approved by" 
Employee Number and Password Entry . 


3. Special Requirements for Enter Cash Qualification Information 

"Do You Own a Car" Text Fields 

These fields could be left blank; there is no validation to make sure information was entered. 
Previously Rented Text Field 

The user can enter whatever they want to. They could enter things like "Last summer", "A few 
months ago". They could also enter date information like "April 2000" or a more formal date like 
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"04/24/2001". The field could also be ieft blank; there is no validation to make sure information 
was entered? 


Password and Employee Number: 

The system requires password and employee number verification when cash 
qualificatio n information is entered during the open ticket process. Ihe system 
will not require passw ord and employee numb er verificati on during the 
reservation process. 


4. Pre-Conditions 

A user is already authorized through a login process to access the panel that is necessary to: 

• Create or edit a reservation. 

• Open, edit or close a rental ticket. 

5. Post-Conditions 

6. Extension Points 

7. Questions 

Question: How should the Employee Number Approval field work? Should this field be: 

1 . Automatically populated (and display only) based upon the user that is currently logged on 
and opening the ticket? (This assumes person opening ticket is also doing the cash 
qualification.) 

2. Automatically populated based upon the user that is currently logged on and opening the 
ticket but able to be changed? (This assumes person opening ticket is also doing the cash 
qualification but also allow changes.) 

3. Blank upon initial entry and allow entry of any employee (valid) number? (No assumptions 
about who is doing the cash qualification.) 

4. Blank upon initial entry and have security to authorize employee number? (This way a 
manager could "authorize" a cash qualification with security.) 

Answer: Since Cash Qualification information is a serious matter, the input from Jon and Mary 
is that the last choice is what they wanted. The user will need to enter a valid employee number 
and update code combination. However this will only be required for an open ticket. 


Question: What European requirements are there? 

Answer: Jon Jouris has indicated there could be translations for the U.K., Germany etc. Fields 
could be eliminated or labels could changed. 

As of 06/01/2001 : once the feedback from the review has been integrated, an electronic copy of 
this document will be forwarded to the proper parties for European requirements and 
translations. 
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Revision History 


Date 

Version 

Description 

Author 

6/14/01 

1.0 

Initial Draft 

M. Pallia 

6/25/01 

1.1 

First Draft 

D. Beebe 

6/27/01 

1.2 

Revisions after meeting and getting 
feedback from Maribeth, Mike P. and 
Jackie L. 

Changes are: 

• Rewriting for clarification. 

• Restated Brief Description. 

• Explained that Notes is accessed 
via a reservation or ticket. 

• Added detail to "Notes Summary" 

• Pulled sort orders and defaults 
from Special Requirements and 
back into document. 

• Added Questions to be asked of 
the business. 

D. Beebe 

06/28/01 

1.3 

Revisions after feedback in meeting 
with Marty Tichy. 

Changes are: 

• Date and Time combined since 
they are saved in the Notes 
database as one field. 

• Multiple users should be able to 
view the same note or notes. 
However only one at a time can 
edit. (This is application wide 
standard and does not belong in 
use case.) 

This is the version sent to Mary and 
Jon for the User Review on 7/2 

David Beebe 
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7/5/01 

1.4 

Revisions based upon feedback from 
Mary and Jon. Changes are: 

• Add Status (Reservation, Open and 
Close) to Summary 

• unange avanaDie iNOie i ypes 10 
System, Callback and Internet 
Shop. Shop, Bill-To and Renter will 
be available in a later 
enhancement. 

David Beebe 




• Removed from Add Note Sub Flow 
the ability for the user to select the 
Note Type. All Notes currently 
added will be "Callback" type. 


"SI J? 

fi 

III 
01 

S"" 3 
?^ r 



• Added the ability to Print a 
particular note or the entire 
summary list. 


L £ 

y| 

8/6/01 

1.5 

Assigned requirements to Iteration and 
approved for testing. 

Jackie Lambert 


8/6/01 

1.6 

Updated Notes Types 

David Beebe 

! s i 

fij 

' 

r 

09/04/01 

1.7 

Added information to supplemental 
requirements indicates what date and 
time the system displays when viewing 
saved note(s). 

Dave Beebe 


11/09/01 

1.8 

Removed requirements to Print Current 
Page. 

Dave Beebe 


Confidential 


©Enterprise Rent-A-Car ? 2001 


Page 3 


ECARS 2.0 

Version: 1.8 

Rental Redesign/ECARS 2 

Date: 12/20/01 

C:\WINDOWS\TEMP\Notes.doc 

Table of Contents 



i . Notes use oase 


0 

1.1 Brief Description 


5 

2. Flow of Events 


5 

2.1 Basic Flow 


5 

2.1.1 Selection to View Notes 


5 

2.1 .2 System Searches for Notes 


5 

2.1.3 System Displays Notes Summary 


5 

2.1 .4 Option to Add Note, View Note Detail, Print Notes and change displayed Note Types 

6 

2.1 .5 Add Note, View Note Detail and View Summary Based Upon Note Type Subflows 

6 

2.2 Add Note Subflow 


6 

2.2.1 Select to Add Note 


6 

2.2.2 Add Note Information Area 


6 

2.2.3 Option to Save and Option to Cancel 


6 

2.2.4 User Entry of Note 


6 

2.2.5 User Selects Option to Save 


6 

2.2.6 Validation Note was entered 


7 

2.2.7 Save Add Note information 


7 

2.2.8 End 


7 

2.3 View Note Detail Subflow 


7 

2.3.1 Select to View Note 


7 

2.3.2 View Note Detail Area 


7 

2.3.3 Option to Close View Note Area 


7 

2.3.4 User Selects Option to Close the Viewed Note 


7 

2.3.5 End 


7 

2.4 View Summary Based Upon Note Type Subflow 


8 

2.4.1 Select to View Summary Based Upon Note Type 


8 

2.4.2 Display Possible Note Types and Ticket Status to sort from 

8 

2.4.3 Options to Print 


8 

2.4.4 User Selects Note Type 


8 

2.4.5 System Searches for Notes 


8 

2.4.6 System Displays Notes Summary 


8 

2.4.7 Print 


Q 
O 

2.4.8 End 


8 

2.5 Alternative Flows 


9 

2.5.1 No Note 


9 

2.5.2 Cancel 


9 

2.5.3 Print All Notes 


9 

2.5.4 Print Note 


9 

3. Special Requirements for Notes 


9 

4. Pre-Conditions 


10 

5. Post-Conditions 


10 


6. Questions 10 


Confidential 


©Enterprise Rent-A-Car, 2001 


Page 4 


ECARS 2.0 

Version: 1.8 

Rental Redesign/ECARS 2 

Date: 12/20/01 

C:\WINDOWS\TEMP\Notes.doc 


Use Case Specification: Notes 

1- Notes Use Case 


1.1 Brief Description 

This use case describes how the user interacts with the system to view all notes 
associated to a ticket or reservation, select to view certain types of notes, add a 
new note or view the full details of a previously entered note. 


2. Flow of Events 

2.1 Basic Flow 

2. 1. 1 Selection to View Notes 

The Notes Us e Case begi ns when the us e r navigates io M^^ MMMMIM^ ^^ or tic — 
""■ ' Yhis could taKelMace at any point In the r eservation and ticket process. (Not es can be viewedat 
an y point iFthelicket process: when creating a reservation, editing th ejBseryMlo^ opening a 
gtujjng ther^ervit^ ticket, closing the ticket and afierjhe^^ 

• rinsed. Notes will carry ^ ^^^^^^^^^ to^cket^enM u $ m Q l M 

Feservation J 

2.1.2 System Searches for Notes 

The system searches for and retrieves all notes associated to the reservation or ticket . 


2. 1.3 System Displays Notes Summary 

The svstern displays the notes to the user yja_symn^ On initial entry to the Notes 
Sumrmrv List the s ystem will display all notes, regardless of type, sorted from the newest to 
oldest bv date a nd time. The columns 'Sispii vidlo the user ar e the following: 

• Date and Ti me (when the note was, saved) 
© Note 

• Status 

c Reservation 
c Open 
c Close 

• Note Type 

o Reservation 

c Shop 

o Bill-To 

o Renter 

o System 

o Callback 
e Created By 
» ARMS message status: 

o (Blank) 

o Sent 
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2. 1.4 Option to Add Note, View Note Detail, Print Notes and change displayed Note Types 

The system displays the o p t ions to sejectt o. 

• Add a new note to the reservation or ticket. 

« View a single note that ^^^^^ ^^^SjQliM= 

• Print (either the Cu7rent P ageo i ^LNotes) 

• Vievvnotes of a oaiiajlaPfvpe and /or Status 

2. 1.5 Add Note, View Note Detail and View Summary Based Upon Note Type Subflows 

Depending on user preference, he or she vv | use one of the following three sub-flow s: Add Note, 
Vj^^^ Vi^aimiTiary Base d UponJ^gfeJyPg . More commonly, the Add Note 

.qnh-flnw is used. If the user se lects to prinialt Notes (reg ardless of Note Type and Statusjthg 
use case continues at alternate How Print AjLRecords^ 

2.2 Add Note Subflow 

2. 2. 1 Select to Add Note 

The user se lects to add a Note to the reservation or ticket . 

• (A Note can be added at any point in fne ticket process: when creating a reservation , editing 
the reservation, openlnoa ticket using the reservation, editing the open ticket, closing the 
ticket and "after the ti cket is closed] 

• System generated notes are defined in individual use cases. However they will use the same 
write process as manuaO^qtes 7~ 

2. 2. 2 Add Note Information Area 

The system d isplays the are a for the user to enter the Note. (MMm!M nt proposed for the 
MureTSvstemjIso dispiaysthe area for theuser to sel ect the Note Type. The p ossible Note 
Tvoes areTCallback. Sho p Bill-To and Rj njjLj 

2.2.3 Option to Save and Option to Cancel 

The system displays th e option to: 

• ^ ave 

• Cancel 

At anv pdnt during the Add Note process the user coul d decide to exit at which time the use case 
^QldcorliTue at alternlitello^ cancels without making an entry, no 

feedback message will be^iiplayedj. 

2. 2. 4 User Entry of Note 

The user enters the note. 

2. 2. 5 User Selects Option to Save 
The user selects to Save. 

Z2.6 Validation Note was entered 

The system validates that a note has beenentere& IfJ^gjyj^mJgjjMinii a note was Sgl 
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entered the use case will continue at alternate flow No Note. 


2. 2. 7 Save Add Note information 

The system saves the note, This system gso saves information from the following areas: 

• Date and Time 

• Note 

• Status 

0 Note Type of "Callback" 

• Created By , . 
Th^TuserWrTot be able to select t heJM gJye^da t e & time - status and the 
^^Created^v" party. Theseltems^e determined and populated bv the system. 
(As stated above, future proposed enhancements will allow the user to select the 
Note Type.) 

2.2.8 End 

The system closes the Add Note area andjhe use case ends. 


2.3 View Note DetaiS Subfiow 

2. 3. 1 Seiect to View Note 

The user selects to view the details of a single, previously entered note within the summary list of 
notes for tT^seiected reservation oxljckiL 

2.3.2 View Note Detail Area 

Thesvstem displays the Note Detail shgyving: 

0 Date and Time 

© Note 

m Note Type 

• Created By 

• ARMS message status : 

2.3.3 Option to Close View Note Area 

The system dis plays the option to dose the area that displays the details of a particular note. JM 
~^M^o^so\^^ ^^^^^ ^^^^^^^^ " 

2.3.4 User Selects Option to Close the Viewed Note 

The user selec ts to close the View Note Detail area. If the user selects to print the current Note 
the use case continues at alternate flow Writ Note. 

2.3.5 End 

The system closes the View Note Detail area and the use case ends. 


2.4 View Summary Based Upon Mote Typ e^uWIow 
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2.4. 1 Select to View Summary Based Upon Note Type 

The user selects to the view notes summej-^gTacertain notejype. 


2.4.2 Display Possible Note Types and Ticket Status to sort from 

The system displays the list of possible No teTypes to seiecf to sort from: 

_ - 

• System 

• internet Shop 

(Futum£^^^^^M3£MM^ WH a!loy v J he user t0 select t0 also SOft from - h0jX Bill ~ T Q-gM 
Renter.) 

Thesvstem displays thejs^^ 
9 Reservation 

% Qp en - 

• Close 

2 A. 3 Options to Print 

... The svsten displays the option to: 

• Print All Notes 

2.4.4 User Selects Note Type 

The user selects a Note Type they want to view. 

2. 4. 5 System Searches for Notes 

The system searches fo r and retri eves notes associated to the ticket or reservation . 

2.4. 6 System Displays Notes Summary 

The system displays the notes 10 the user yg a summary Vst The coiumns displayed to the user 
ire the following: 

• Date and Tjme 

• Note 

• Note Type: basedjjponjh^ 

• " Created By 

• ARMS message status 

2.4.7 Print 

If the user selects to print all Notes (regardless of the currently displayed Note Type) the use case 
continues at alternate flow Print All Notes . 

2.4.8 End 

The use case ends. 
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2.5 Alternative Flows 

2.5.1 No Note 

2.5.1.1 The system displays a feedback message: "Please enter a Note if selecting to Save." 

2.5.1.2 The user has the optionjo: 

• Enter the note 

• Exit the Add Note process 

2.5.1.3 If the user selects to enter the note, use case proceeds to User Entry of Note in the Sub Flow 
t7 Add NofiT . If the user selectilb exit the Add Note process the use case ends. ~ ~ 

2.5.2 Cancel 

2.5.2.1 The system displays a feedback message : "Are you sure v ou want to exit and lose the entered 
irTformationT 7 "" 

2.5.2.2 The user has the options: 

0 Y§s (exit and iose the information) 

• Nojjeti^ the us e case at th e point where the user selected to exit from.) 
The default option will be "Nol 

2.5.2.3 If the user jelectejoexit the Add Note process, the use case proceeds to System Displays Notes 
Summary in the Basic Flow . If the use r selects No, the use case proceeds to User Entry of Note 
FTfhe Addl^teSubflow. 

2.5.3 Print AH Notes 

2.5.3.1 The system initiates the Print Use^Case. 

2.5.3.2 The use case returns to the point where the user Initiated the print fu nction 

2.5.4 Print Note 

2.5.4.1 The system initiates the Print UgoCase . 

2.5.4.2 The use ca se returns to the point where the user initiated the print function. 

3. Special Requirements for Notes 

• Previously entered notes may not be edited or deleted by the user. 

• ystem generated and manually entered) will be displayed based upon the date and time of 
the physical terminal location of the user viewing the notes. 

4. Pre-Conditions 
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• A user is authorized through a login process to create or edit a reservation or 
ticket. 

« The user has accessed a reservation or ticket, either in the process of editing 
or creating. 


5. Post-Conditions 

6, Questions 
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Business Use Case Specification: 
Open Retail Rental Ticket without Payment 


1. Open Retail Rental Ticket without Payment Use Case 
1.1 Brief Description 

This use case will describe how the user and system interact to create a retail 
rental ticket. It will show the flow of events that occur when information is 
entered into a new retail type rental ticket so that it is completed. 


2. Flow of Events 

1.1 Basic Flow 

111 Search Criteria 

The Open New Retail Re ntal Ticket Use Case begins when the system display sjheareafor 
entry o f search criteria fo n^ IM. gvstem displays all search criteria 

fields blanked out aliowiQfljhea^ *nfonmation; 

• Phone Number "" 
<* Last Name 

• First Name 

• Driver's License Number 


1.1.2 Options to Search, Clear/Reset and to select to Enter New Driver 

The system displays the option to selecU ooerfo rm the search from information 
• : . above fields. IhejYstem^ajs^d is^a^ 

9 the'optionTor the user jojgseUlhe entered information. 
to enter New Driver informatio n 

1.1.3 User Entry of Name and Phone Number 

The userenters the renter's first an^^:tjiame and telephone number, (Last name could 
jffierW E stlhe first tQ ente lljgw 

DrfveMrTfo rmation theTIse^asewilJ_^ at System Performs Reservation Searchjnjhe 
basic flow. 


1. 1.4 User Selects Search Option 

The user selects the option to perform tne search. If the user only enters only the lastjname 
anc j selects to search, the use case will continue at Need More Search Criteria alternate flow. 

1.1.5 System Performs Repeat Renter Search 

The system performs the sear0Jgun^f^Q repeat renter information if a renter's telephone 
number was entered in The initial s earch criterjaarea If information was not entered in the "" 
renter^steiephone number area, Th ejus£cas e will continue at Renter Persona! InformationArea 
in one of the subflows. 
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1.1.6 System Performs Reservation Search 

The system searches for all the [^g^^^c^y^m^bihg Information entered. The searchfor 
the namewili be a wildcat d searchT^ 


1.1.7 Reservation Search Results 

The system finds no mafcning reservations and the use case continues at the next step in the 
basic flew. I f the search produces o ne^LS^ . m3tching branch reservation then continue at 
alternate fiowMatching Branch Reserva ^onCgl [fjhesearch produces one or rngrejmatc^ 
Nat Res reservation, then continue a^ flow Matching Nat Res Reservation. 

1. 1.8 Repeat Renter Search Results 

The system produces no matchingreQeg|^oter recordsand the usecase continues at the 
nexfstep"in the basic tiow^^^^^^ ::: ^^^ces ^^^^^^^^^^^^^^^^ match, 
Fhen continue^aiternatellow MatchjnaRe^ 


1.1.9 Renter Personal Information Area 

The system displays th e area for ent ry and selection of information abou t the renter. The fields 

In this area are: 

Name: 

0 Last Name 

• First Name 

Phone Number 

• Home Phone Number 

® Work Phone Number (and^ension) 

• Employer 

• Other Phone Numbe r ( and phone ty pe) 


Home Address 

9 Address 

© Zip/Postal Code 

* Country 

• g& 

© State/Province 


Driver's L icense 
• License Number 


Exp is 

*ation Date 

Issui 

no Country 

State 

3 Issued 


Date of Birth 
Eye Color 
Height 


9 Hair Color 

WeiqFT" t The system also displays the^option for the user to enter thewort address. If the user 
ieiectTfheoption, the usecase continues at alternate flow Work Address Information Entry. 
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1.1.10 Option to Complete 

The system displays the option forjhe^'ser to complete the ticket At any point the user could 
select this option. 


1.1.11 Personal Information Area Field Population 

Unless a reservation or repeat renter jgfe£g||jgg = has been applied to the ticket the system 
populates the matching fields witha^^Q|grmation previously entered in the basic fiowsteg 
User Entry of Name and Phone Numbe r (See Special Requirements for table showing how 
information from the Initial Search CrilrTa Area fields is populated in the matching Renter 
Personal Information Area fields.) 

The system also Bj^JSiJS^==2S~= ^ Qrma ^ on Area fields available foredit The 
country , based upon the profile of the renting branch location, will be defaulted Into the Country 
field. ~ — ~~~~~~~~ ~~~~ ^ ~~ ~ ~~~ ~ 

1.1.12 Address and Zip/Postal Code Information Entry 

Jhe user enters the Address and Zio/Pos ta[Co^ 

11 1 3 Zip/Postal Code Search Option 

Jhe system displays the option to searc^Jortne City and State/Province based uQpnjhe 
Zip/Postai code and Country 

1.1.14 Zip/Postal Code Search Selection 

The user selects the opti on and the system performs the search for the City and State/Province 
that match the Zip/Postal Code and Country, 


1.1.15 Zip/Postal Code Search Results 

The system searches for and produces a single City and State/Province result and continues at 
the nexfstep in the basE^ Mi l|i5g^^IgtL p rod u ces no matching city and State/Province 
Information, the use ca^conti n ug|j|j^em ate flow No Match to Zip/Postal Coda If the 
. search produces multlBjejsi^ at alternate flow Multiple City Results. 

1.1.16 City and State/Province Field Population 

The system populates the City and^Stai^/Province fields, The system also makes the 
information in these fieidsavailabie for edit. 


1.1.17 Phone and Driver's License Information Entry 

The user enters the home phone numbarvwork phone number, other phone number and 
selects tne other phone number typeTTSee Special Requirements for list of "Other" Phone 
Number Types.) The user also enters the License Number, License Expiration Date, State 
Issued, PateoTBirth, Social Security J^ umb^Height, Weight, Hair Color, Eye Colorand 
selects t he Work Address^Qg tjgg, ^^ use case continues at alternate flow Other Address 
Information Entry. 


1178 Cash Qualification, Renter's Insurance and Additional Driver 

If cashqualification information needs to be gathered about the renter, the use case continues 
at alternate flow Cash Qualification Information. If insurance detail information needs to be 


CONFIDENTIAL 


©Enterprise Rent-A-Car, 
2001 


Page 8 


Rental Redesign 

Version: 2.0 

Business Use-Case Specification 

Date: 12/20/01 

C:\WINDOWS\TEMP\Open Retail Rental Ticket Without Payment.doc 

qathered about the renter, the use case continues at alternate flow Insurance Information. If 


there are additional driver(s) and information needs to be gathered, continue at alternate flow 
Additional Driver. 


7.179 Referral Information 

This use case extends to the Referral use case for entry^validation and saving of all 
information concernirialhe^eferral sourc eT" 

7. 7.20 Dates and Rates 

This use case extends to the Dates/Rates use case for entry, validation and saving of all 
Information concernTn^diles, rates, taxes and surcharges, While in the Dates/Rates area the 
user seiecFs a rentafvehicie to be applied to the ticket 

7. 7.27 User Selects Option to Complete 

Jhe user selects the option to coniple^iiejic^ 

7. 7.22 System Displays Complete Options 

The system displays the option forjlie^gerto select the following type of complete tickets 

• "Complete" If thejjger selects "Complete", the use case 
continues at subfiow Complete Ticket, 

• "Complete - Unit Pend* i the user selects "Complete - Unit Pend". 
thejjse case continues at subfiow Complete - Unit Pend Ticket 

• "Complete - Frewrite" If the user selects "Complete - Frewrite", the use case 
continues at subfiow Complete - Frewrite Ticket. 

1.2 Complete Ticket Sub-Row 

7.2. 7 User Selects Complete Option 

The user selects the "Complete" option. 


7.2.2 Validation of complete Renter Information 

The_sxstem validates that informafjon^ i ncernina the renter exists h all of the following areas: 

Name: 

• First Name 

• Last Nime 

Address: 

• Address 

• Zip/Postal Code 

• Country 

• City 

• State/Province 

Driver's License: 

• License Number 

• License Expiration Date 
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• State Issu ed 

• Date of Birth 

• Social Security Number 

• Height 

• Hair Color 

• Eve Color 

12.3 Validation of Driver's License Expiration Date Information 

Jhe system validates that the information entered in driver's license expiration date field for the 
renter and additional drivers is greater than the current date. If user enters a driver's license 
expiration date that is less than the cur. e ot date, the use case continues at alternate flow 
Expired Driver's License . if the user emers a driver's license expiration date that is the same 
as the current date, the use case con jjgj ^es at alternate flow . Driver's License Expires Today. 

12.4 Validation Of Date of Birth Information 

The system validates that the Date of Birth for the renter and additional drivers is not greater or 
less than the restrictions for rental jfthe user enters a Date of Birth that results in the renter's 
age being greater than the restrictions the use case continues at alternate flow Over Soft Edit 
Age Restr iction. If the user enters a Dgte of Birth that results in the renter's age being 18-20, 
the use case continues at alternate fiowtinder Age (18-2Q) Soft Edit Restriction. If the user 
enters a~Dite of Birth that results i"rTfhel;enter ? s age being 21-24, the use case continues at 
Under Age (21-24) Soft Edit Restnction^ If the user enter a Date of Birth that results in the 
renters age being less than the hard eoit age restriction the use case continues at alternate 
flow Under Hard Edit Age Restriction. 

12.5 Validation Of Rate Information 

The system validates tne necessary rat^jnformation is complete. 

• If there is a rate in the daily field th e- e must be a rate in the hourly field. 

• Tfthere is a rate in the weekly field there must be a rate in the daily field. 

• Wlhere is a rate in themonthiy fieldThere must be a rate in the weekly field. 

• ^ thereisa rate that either the. unlim'ced. mileage option isseiecteti or that both the 
corrisgonding excess charge and unlimited mileage fields are completed. 

If the system determines "that ^ e ^^J^ r j^gjj ients are not met, the use case will continue at 
alternateflow incomplete Rate Triformatiorv ~ 


1.2.6 Other Validation 

The system validates that a; 

• unit has been selected (valid unit number and license plate or VIN number). 

• Date out and Time Out fields are populated with valid values 

1.2.7 Incomplete Ticket Feedback Message 

if any of the above areas and fields are missing information the system will present the user 
with a feedback message as to what required fields are not filled to print a complete ticket. The 
systeniwil! display the option for theuser to cancel the print action and return to the openlicket 
process. 
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1.2.8 Save Ticket Information 

The system saves all the information e^ered in the fields of the open rental ticket process. 
This would be information from the following areas: 

• Renter Personal Information 

• Cash Qualification, Renter's Insurance and Additional Driver Information 

• Referral Information 

• Rental Information 

• Additional Product(s), Taxes and Surcharges 

The system saves other information that did not come from othenjse^ases. This information 
would be: 

• Ticket Number 

• Employee number of person that opened the ticket 

• Group/Branch information 

• Information about the terminal the ticket was opened on 

Links will take you to the tables/locations in this document that contain the full list of items to be 
saved.) 


12.9 Print Ticket 

This use case extends to the Print Vckei Use case . 


1.2.10 End 

The use case ends. 
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13 Complete Unit-Fend Ticket Sub-Flow 


5 "3 


5 

III 


7.3.-/ Unit Pend Ticket 

This subflow is the -sa meagj^^ that while in the Dates/Rates area, the 

user does not select^p M^5SiEt<L ^Q applied to the ticket 

1.3.2 User Selects Complete - Unit Pend Option 

The user selects the Xoigplete - UniH^end" optio n. 

1.3.3 Complete Unit-Pend Ticket Validation 

The system performs the same vali^gMiasjyie Complete Ticket subflow except thatjiie 
system does not validatethat a uQjLhi^^Qeejijdect^ 


i;f 1.3 .4 Incomplete Ticket Feedback Message 

If any of the above areas and fields are missinq_ information the system will present theuser 
Or 1 with a feedba ck message jisjo^^ fields are not filled to Ennjacgriplete unit 

^ndglEkeTThe syste.niM-displgy option for the user to can cejjher^ and 
I return folEeopen ti c ^ gl£[^gj£: 

1.3.5 Save Ticket Information 

The system saves all th e information entered in the fields of the open rental ticket process. 
This would be information from the following areas: 

• Renter Personal Information 

• Cash Qualification, Renter's Insurance and Additional Driver Information 

• Referral Information 

• Rental Information 

• Additional Product(s), Taxes and Surcharges 

The system saves oth er informationlhatdMilot come from other use cases. This information 
would be: 

• Ticket Number 

• Employee number of person that opened the ticket 

• Group/Branch information 

• Information about the terminal the ticket was opened on 

Links will take you to the tables/locations in this document that contain the full list of items to be 
saved.) 

1.3.6 Print Ticket 

TCs_yse case extends to the Print Ticket Use case. 

1.3.7 End 
This subflow and the use case ends. 
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1 .4 Complete Pre-Write Ticket SyLvFiow, 

1.4.1 Pre Write Ticket 

This subflow is the same as the Corn^L^jlckef except that the user could only enter part of the 
needed information. Whilejnj^ area the user selects a billing cycle and usually 

selects a rental vehiclelFbe applied to Iheticket 


1.4.2 User Selects Complete Pre-Write Option 

The user selects the^Co^ 

1.4.3 Validation of entry of Name 

The system validates that a first and issi name has been entered for thererger. 


1.4.4 Validation of Billing Cycle 

This use case extends to the Dates/^gAygg^Case to verify that a Billing Cycle hasbeen 
selected. 


1.4.5 Validation Of Date of Birth Information 

he system validates that it is not greater orjess than the restrictions forjgntaL KJiejuser 
enters a Date of Birth that results in eitner the renters cxdm/er's age being greater tjianjhe 
restrictions the use case continues jFaitemate flow Over Soft Edit Age Restriction. If the user 
enters a Date of Birth that results in either the renter's or driver's aqebeing 18-20, the use case 
contimjesg alternate ^^^^^^^^^^ Soft Edit Restriction, If the user enters a Date of 
Birth thatresults in either the rent^ ^gny ^r^acie being 21-24, the use case continues at 
Under Agi721-24) Soft Edit Restriction? jf the user ente ra Date of Birth that results in either 
The renters or driver's age being leiilHknlhe hard edit age restriction the use case continues 
at alternate flow Under jjj^ jj^f^^ required for a prewrite T 

however if a date is entered it should be validated,) 


1.4.6 Incomplete Ticket Feedback Message 

If any o f the above are as and fieldsare g^^flj^S S§|j^J^^|!§IS will present the user 
with a feedback message as to wh ah ecju ired fields are not filled toprinf a complete prewnte 

Ticket iSiJYiiibi^dl return t0 ~ 

open ticket process"" 


1.4.7 Save Ticket Information 

The system saves all the \niorma tior ^niere6 in the fields of the open rental ticket process. 
This would be information from the following areas: 

• Renter Personal Information 

• Cash Qualification, Renter's Insurance and Additional Driver Information 

• Referral Information 

• Rental Information 

• Additional Product(s), Taxes and Surcharges 

The system saves other information that^didjiot come from other use^cases. This information 
would be: 

• Ticket Number 
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• Employee number of person that opened the ticket 

• Group/Branch information 

• Information about the terminal the ticket was opened on 


1.4.8 Print Ticket 

This use case extends to the Print Ticket Use case. 

1.4.9 End 

This subflow and use case ends. 

1.5 Alternative Fiows 

1.5.1 Need Mora Search Criteria 

1.5.1.1 The system displays a feedback en^messaqe that the last name cannot be the only search 
criteria and to enter at least one more_critei^ 

1.5.1.2 The user selects to enter another piece of search criteria information and the use case 
proceeds back to User Selects Sear^FQ gtjg^ n the basic flow. 

1.5.2 Matching Branch Reservatignlsj 

1 .5.2.1 If the svstem finds that there is one or more current reservations based upon either the renter 
first and last name, teiepno^^ birth and driver's license number and 

§tate/ProvFce , the system should display all the reservations that match the information that 
was inpu~The return gd^ include the following: 

• Reservation Number 

• Renter First Name 

• Renter Last Name 

• Pickup Date 


Picku 

D Time 

Cs r C. 

:iass 


0 Pickup Branch Location 

• Date Reservation 

• Date ReservationTast Modified 

1 .5.2.2 The system will present a list for the user to select one of the displayed/summarized 
reservations. (See Special Requirements link for what reservations will not be displayed.) 

1.5.2.3 The user selects a reservation from the list and continues at Renter Personal InformationArea 
in the basic flow. The user can also select at any time to cancel out of the displayed list of 
reservations. If a phone number was entered in the initial search criteria area the use case will 
continue at Repeat Renter Search in the basic flow. If a phone number was not entered in the 
initial search criteria area the use case will continue at Renter Personal Information Area in the 
basic flow. 
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1.5.3 Matching Nat Res Resenration(sl 

1.5.3.1 In a later elaboration, the matching of a Nat Res Reservation to an open ticket will betaken 
care ofT 


1.5.4 Matching Repeat RenterRecord($l 

1 .5.4.1 If the syste m finds that t jhgrej^^ that match based upon the 

teieohone^mber, the system shoi^ j^jM^ ll the repeat renter records thairnatohthe 
information that was in^ut The return^ Informatior^^should include the following: 

® Renter First and LastJName 

• Street Address, CityJState and Po staLSg^g 

• Home Phone 
o Office Phone (and extension) 
o Driver License Number 

• Driver License State 

• Dite Of Birth 

• Date Last Rented 

The system should also indicate if any of the repeat renter records on the above summary are 
on the Renter Waminq/oFTIot RejiUJst. 

The system will present the option for tne user to select the repeat renter record to appiytiothe 
open ticket . 

The usgt jg lects a repeat renter recortfrom^^ If the user selects a repeat renter record 
thatjsonlhe Renter Warning/Do Nglvant List, the use case will continue at alternate flow 
Renter Warning/Do Not ff gnL Ihgj^^cari^lso select at any time to cancel out of the~ ~ 
clispiayed list of repeat renteT reco Mill^SQni ^ue at Renter Personal Information Area in the 
basic flow7~ 

The system displays t he Renter Pe rso nal Infogp^tioriArea with theffiormation fronvfog 
selected repeat [MjMyi ^ Thejel dsjn this areaand the 

information" that coul dcomi fro^^^£ £g gl!9 n - er recordare: 
Name: 

• Last Name 

• First Name 

Phone Number 

• Home Phone Number 

• Work Phone Number j and extension} 

• Employer 

• Other Phone Number (and phonetype) 


Home Address 

* Address 

* Zip/Postal Code 

* Country 
© City 

® State/Province 


1.5.4.2 
1 .5.4.3 
1.5.4.4 

1.5.4.5 
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Driver's License 

» License Nu mber 

• License Ex piration Date 

• issuing Co untry 

• State Issued 

• Date of Birth 

• So c;aJ_Securitv Number 

• Height 

• WeTq ht 

• Hair Color 

• Eve Coior 

Thfi system also displays th e option tqc timgQ-ti 16 presented Repe at Renter Personal 
Information."" 

1 5 4 6 If the user sel ects the option to change [he presented Renter Persona! Information, the use 

case^orlnui s at Addresjand Zip/PostelCode Inform^njj^^ basic flow . jnhejj§§E 
to^^^ change the pre sented Renter Personallrr formation, the usecase 

55Htinu^^ andj^fltton^^ 

1.5.5 Renter W arning/Do N ot Rent 

1.5.5.1 If the selected repeat renter record is o n the renter warning/do not rent list the system displays 
aleedback message thatlheTeriter is~cnth^^ 

1 .5.5.2 The system displays the option for the user jo: 

• Exit the op en ticket process. 

• View the d etailed RenFer Warning I ji fo iloMiQIL 

1.5.5.3 The_ys eL§ejects to view the detailed Renter Warning information, ifthe user se lects the exit 
the open ticket procesFootion the ljjecgse continues at alternateJLQ^gM3£glZi^ 

1.5.5.4 The s ystem will display thejw^e^^^ 

m Repeat Renter First and Last Name 

• Street Addrg gg 

• gjty 

• State 

• Posta* Cod e 
9 Home Phone 

• Office Phone (and extension) 

• Dri ver License Number 

• p J iy. : )NJcense State "~ 

• Cjt£ pf Birth 

• Height 

• We-ght 

• Soc ial Security Number 

» The iicket number and group/branch that the wa = mjQg = ^BQ^ was referencegja 
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• Ibe,tex Llnfprm3tion from the reporhlelailing why the renter was placed on the warning/do 
not Tent list. 

• Reportedbv employe e name 

• Reported bv employe e number 
© Reported by employee title 

® Reported b v employee phone num bbj jand^ten^ 

• Reportedj v employeeqroup/brancn jocatign 

• DiteTeported 

1.5.5.5 The system displays the option to either ^ent or dojiojlMlL 

1 5 5 6 The user sele cts to rent and the use ease continues at Renter EgQ ^iUSfe^§li£0 Area in th - 
basEfl^ user selects "Do Not We nt\ the us e case continues at alternate flow 

notified™" 


1.5.6 No Match to Zip/Postal Code 

1.5.6.1 The system displays a feedback message that the zip/postal code and countr y combination 
doesnoTproduce matching city and sta tej&g^ 

1 .5.6.2 The system prompts the user to manually enter cit y and state/province information. 

1 .5.6.3 The user selects to manually enter city and state/province information and the use case 
proceeds back to Phone and DriyePsTicenseJnfo Entry in the basic flow. 

1.5.7 Multiple City Results 

1.5.7.1 The system d isplays a fee dback message that the Zip /Postal Cod e and Country combination 
producesTnore than one matchinq city, 

1 .5.7-2 The system displays the l ist of cities aroprompts the user to sel ect a City, 

1 .5.7.3 The user se lects a City from the list thejjsecas e proceeds b ack to City and State/Province 
Field Population in the bjiic^owT^ 


1.5.8 Other Addre ss Informa tion Entry: 

1 .5.8.1 The system d isplays the area for entr xand_sel ection of other address info rmation about the 
renter The fields In this area are: 

• Address Type 

• Adoress 

« Zip/postal Code 

• Country 

• State/Province 

1.5.8.2 The country, based upon the profile of the renting b ranch locatio n, will be defaulted into the 
Country field . 
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1 .5.8.3 The user enters the Address and Zip ^ siajCode, 

1-5-8.4 The system displays the option to s^rcMorJi§ city and State/Province based uponjhe 
Zip/Postal Code and Country 

1.5.8.5 The user sel ects the opti on to performjhe search forjhjCitya nd State/Province that match 
the Zip/Post aTCode and Country, 

1.5.8.6 The system searches for the City and Jgtate/Provincejhat mat <^}gZiPjgQstal Code and 
Country, 

1.5.8.7 The system produces a sinaSe City ano ,,§iate/Province result and continues at the next step in 
the basic flow . If the search ^^^^^^^^^^^^^ State/Province information, the use 
Sise^iinues aFaltirTaie fiow No Metcn to Zip/Posta[Code. IQhesearch produces multiple 
"cities, th e use case c^ fjn^^^ City Results, 

1.5.8.8 The system nopnteies tne Citv and State/Province fields. lD£ = ^i|gmjji2 = M^=M 
inforn^iorTln these fieldFavailaDlefag: ec jt 

1.5.8.9 The system displays the option for the user to exit a nd return to the basic flow. 

1.5.8.10 The user sel ects this option and the uae case proceeds back to Renter Personal information 
Area in the basic flow. 


1.5.9 Expired Driver's License 

1.5.9.1 The system displays a feedback m ^gg petjiat the entered driver's license expiration date is, 
invalid because if is less than the current date. 

1.5.9.2 The system prompts the user to: 

• Change/enter valid ex piration date, 

• Exit the o pen ticket process, 

1.5.9.3 if thlTuser selects to change the ex^aronjdate, the use case proceeds back to Phone and 
Drivers License lnfQrm atiQn_Entrv in the basic flow. Ifthe user selects to ex it the open ticket 
processthe use case continues at alternate flow Cancel/Exit. 

1.5.10 Driver's Lic ense Expi res Today 

1.5.10.1 The system displays a feedback mess age that the MSiM^rwe^ date is 
.teli mi as the ^^[[ggijg M: 

1.5.10.2 The system prompts th e user to: 

• Continue with the op en ticket process 

• Change/en ter different expiration d|t| 

• Exit the open ticket Pf££gg| 

1.5-10.3 If the user selects to continue with the open ticket process, the use case continues at Cash 

Qualification, RenteFsTnsurarice and Additional Driver In the basjcflow . if the user selectsjto 
change the expiration date, the"usecase proceeds back to Phone ar^Driver ? s JJcense 
iHforma^ in theTa sicflow . Ifjh euser selects to exit the open ticket process the use 
case" continues at alternate flow Cancel/jggjL 
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1.5.11 Over Age S oft Edit Rest riction 

1.5.11.1 The svsfem d etermines t hat the age o f jne renter Is equal to or greater than 70 years oteL 

1.5.11.2 The svstem displays a f eedback m^sjgejhM^ of birth res ults in the age of 
theTenjeF be^ over the age restriction" ;pi|p ygtemIalso displavsjhe entered date of birth" 

1.5.11.3 The svstem prompts t he user to: 

• Continue with open ticket process. 

• Enter corre ct date of birth, 

• Exit the Qpgniig^gjgiggg^ 

15114 If the user sel ects to conti nue^igiM : gP en ticket Brocgssjfoe^ ^ continu es at Cash 

Q^^^^^^^B |n ^ r gHgg^^S k lion31 Drive r jn the basic = i^^ ser selects tQ - 

chanoiW birthrtheu^^epf oceeds back to P hjoneanlp river ? s License 

Information Entry in the baWflowT £tne user sel ects to exit the open ticket process, the use 
caii continues at alternate flow Cgng^i/jxjL 


1.5.12 Under Aae (18-20) Soft Edit Restriction 

1.5.12.1 The svstem determines that the age ot the renter isJ8to 20 years old, 

15122 The svstem d is plays a feedback message that the entered date of bi rth results in th e age of 
the renter be ing under the aoe restriction, The system also displays the entered date of birth 
and the renter's age. " 

1.5.12.3 The system prompts the user to: 

• Continue with open tic ket process. 

• Enter correc LjMi£llE^ 

• Exjjjheofien ticket pr ocess. 

15 12 4 If the user sel ects to ^D|l DMi = ^JbiJ giO ticket ^ rocess - the use case c °ntln ues at Cash 
Qgli^iTnn ^nH RahI sr's I n si. j r an cTi^jh e basic flow. If jne -user selects to change t he date of 
flfOHf^^ Driver's License I nformation Entry in the^asic 

flow if the user selects to e xiFtheope^ at alternate flow 

Cancel/ExiF^ 

1.5.13 Under Aae (21-24) Soft Eaii Restriction, 

1 .5.13,1 The svstem determines tha t the age of the jwiterjis 21 to 24 years old. 

1 5 1 3 2 The system displays s feedbaci^^ 

th^TSnte FbiinQ under the aoe restriction^ Thesvstem also displays the entered date of birth 

and the Tenter's age. 


1.5.13.3 T h^svstem prompts the user to : 

• Continue with open ticket^process. 

• Enter correct date of bjrjh^ 

• ExjUhewen ticket P^cjig, 

1.5.13.4 If the user selects to continue with the open ticket process, t he use cas e continues atCasj} 
Qualification and Rent^ilnsura^ If the userselects t o change the_dategf 
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birth, the use case proceeds back to Phone and Driver's License Information E ntry in the basic 
flow. If the user selects to exit the open ticket process, the use case continues at alternateflow 
Cancel/Exit. 


1.5.14 Under Age Hard Edit Restriction 

1.5.14.1 The system determines t hat the age of the renter is equal to or u nder the age of 17 years 
old. 

1.5.14.2 The system displays a feedback message that the entered date of bi rth results in th e age of 
the renter be ing under the age restriction. ThesysteriLalso displaysjhejentered date of birth 
and the re nter's age. " 

1.5.14.3 The system prompts t he user to: 

• Correct the date of birth. 

• Exit the ope n ticket process. 

1.5.14.4 If the user se lects to ch ange the date of birth, the use case proceeds back to Phone and 
Drivers Lice nse Informa tion Entry in the basic flov^ If the user selects to e xit the open ticket 
processjhe use case continues at alternate flow Cancel/E xit, 


1.5.15 Additional Driver 

1 .5.15.1 The system d isplays the area for entry and selection of information about the additional 
ririvgr. The fields in this area are: ~ 
Name: 

* Last Name 
First Name 

Phone Num ber 

* Home Phone Number 

* Work Pho ne Number (and extension) 

* Employer " 

Other Phone Number (and ^hon^Mg) 

Home Address 

* Address 

« Zip/Postal Code 
© Country 

9 State/Province 


Driver's Li cense 

• License N umber 

• Expiration Date 
© issuing Country 

• State Issued 

• Date of Birth 

• Social Security Number 
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• Height 

• Weight 

• Hair Color 

• Eye Color 

1.5.15.2 The system displays the option to sea r ch for the Repeat Renter Information for the additional 
driver based upon the home phone numb er. 

1.5.15.3 The user enters home phone number of the additional driver, 

1.5.15.4 The user selects the option and the system performs the search for matching repeat venter 

information. 

1.5.15.5 The system produces no matching repeat renter records and the use case continues at the 
next step in this alternate flow . If the system produces one or more matching repeat renter 
records, the continue at alternate flow Matching Repeat Renter Record(s). 

1.5.15.6 The user enters the first and last name of the additional driver. 

1.5.15.7 The system displays the option for the, user to select that the additional driver has the same 
address information as the rente r, if the user selects this option, continue at 1.5.15.14. in this 
(alternate) flow. 

1.5.15.8 The user enters the street address and zip/postal co de. 

1.5.15.9 The system displays the option to search for the City and State/Province based upon the 
Zip/Postal Code and C ountry. 

1.5.15.10 The user selects the option and the system performs the search for the City and 
State/Province that match the Zip/Postal Code and Country. 

1.5.15.11 The system searches for and produc es a single City and State/Province result and 
continues at the next step in this alternate flow. The system also makes the information in 
these fields available for edit. If the search produces no matching city and State/Province 
information, the use case continues at alternate flow No Match to Zip/Postal Code. If the 
search produces multiple cities the us e case continues at alternate flow Multiple City Results. 

1.5.15.12 The system populates the City and State/ Province fields. The system also makes the 
information in these fields available for ed it. "~ ~" ~ " " ~~ 

1.5.15.13 The user enters the home phone number, work phone number, other phone number and 
selects the other phone number type. T he user also enters the Drivers License Number, 
Driver's License Expiration Date, State Issued, Date of Birth, Social Security Number, Height, 
Weight, Hair Color and Eye Colon (S ee Special Requirements for list of "Other" Phone Number 
Jype.) The system also displays the^ptfon for tbeuser to select/list the additional driver *w(th~ 
valid lice nse" . If the user selects this option, the use case continues at the next step in this 
alternate flow. 

1 .5.15.14 The system displays the area for entry of additional driver's credit card information. The 
fields in this area include: 

• Credit Card Number 

• Credit Card Type 

• N^melhifipDeirs on the Credit Card 

• Expiration Date 


CONFIDENTIAL 


©Enterprise Rent-A-Car, 
2001 


Page 21 


Rental Redesign 

Version: 2.0 

Business Use-Case Specification 

Date: 12/20/01 

C-\WINDOWS\TEMP\Open Retail Rental Ticket Without Paymentdoc 


(There is currently no validation or processing of the entered credit card information.) 

1.5.15.15 If cash qualification information needs to be gathered about the additional driver, theuse 
case continues at alternate flow CasjvQuaiification information, ^insurance defaii information 
^eedstcbeq athered ab out the additi^d driver, the use case continues at alternate flow 
Insurance information,"" 


1.5.15.16 The syste m displays t he option ^oLj lgJjj£LM 
» Add more additional drivers. 

• Exit and ret urn to the basic flow. 

1.5.15.17 If the user se lects to ad d more additional drivers the system adds another blank addjtiongl 
driverareaa nd returns to the first step of this alternate flow. If the user selects to exit the use 
case returns to the point .n the basic flgw where the user selected to add the additionai driver 
information. 

Cash Qualification information 

If the rental r equires cash qualificatio n information about the r enter or addit ional driver the 
use case extends to the Enter Cash Qualification Inform ation Use CaseT ^ 

Insurance Information 

If the rental requires in surance information abou t the renter or additional driver the u se case 
exleidsloThe^nter R^er's/Additi ona LDriy^ insurance Information Use Case, 

Cancel/Exit 
The user selects the option to cancel/exit. 

1 .5.1 8.2 The system displays a feedback message warning that the entered data will be lost if they 
select to c ancel/exit. 

1 .5.1 8.3 The system displays the followinqoptjons: 

• Yes: to exit and losejMa, 

• No: return to the use case they just selected to exit from. 

(The default option will be No: retur n to the ar ea where the user selected_the 
Cancel option from.) - 

1.5.18.4 The user selects Yes the use case ends. If the user selects No then continue in basic flow at 
the point where the user selected to cancel/exit. 

2. Special Requirements for Open Retail Rental Tick et without Payment 

3.1 All lists in this document are the order that items should be placed. 

3.2 The information entered in the fields of Initial Search Area will populate t he fields of t he Renter 
Personal Information the following mannerT ^ 

Initial Search Area 

Renter's Telephone Number = Hom e Phone Number 
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Renters Last Name = Last Name 

Renter's First Name = First Name 

Dnyer^License Number = Driver's License Number 

3.3 List of Other Phone Number Types: 

• Home 
Work 

• Cell/Mobile 

• Pager 
Other 

3.4 With the last name the system searches in the same group as the renting branch for a match on the 
textapplvinq from left to right on the number of characters for records by the enter ed name. (There is 
jFTimpffed wildcard at the end of the character set entered, but no leading or imbedde d wildcards 
within the character set.) 

3.5 Later enhancements to the open ticket process will pre-populate information into the appropriate rate 
information fields. 

3.6 Types of reservations not shown in the list are as follows: 

• Voided reservations 

• Reservations that are attached to an open ticket. 

• Reservations that were attached to a ticket when it was closed. 

• Available reservations where the Pick-up date is greater thaivS calendar days ago. 

3.7 if a user cancels out of the open ticket process and a reservation had been pr eviously applied, the 

reservation becomes available again. 

3. Pre-Conditions 

A user is authorized through a login process to access the panel that is necessary to open 
ticket. 

4. Post-Conditions 


5. Extension Points 


6. Questions 
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Business Use-Case: Open Ticket Get Rates using Perot Engme(s) 
1. Open Ticket Get Rates- 


1,1 Brief Description 

The purpose of this use oa^is^^Bmm cojdg ^^ must be fed from the 

ECARS 2.0 system to the F eroy|gg^^ to retrieve the appropriate rates for each 

product foPfhe rental transactiorT in l^^gi ^se the products for which a rate is to be retrieved 
j^ jig-YgfilS and a11 ap. gjk|*bie^ and SLPY The ECARS 

2.0 systemTwill provide the Perot system w j th specific information about the transaction in order to 

transaction"" 


3«a 


f ":1 1 

o 


f si 


J s \ 


2. Flow of Events 
2.1 Basic Flow 


2.1.1 Use Case Begins 

This use case should be able to be invoked from anywhere in the Open Ticket process and 
initiate the request for rates, f or appropriate products (in this case vehicle and CGveraqesjJrom 
the Perot Enqine(s) for a specific rental transaction. {Eventually, this use case will evolve intolhe 
one, which is used to get rates fo r all functions, Reservation, Open and Pre-Write) 

2.1.2 Information Needed For Rate Retrieval 
The ECARS 2.0 system will need to provide specific information from the transaction to the Perot 
system to retrieve rates. Perot will require specific information before it will be able to search for 
products and their associated rates. Below is the list of items the Perot system will need to 

? » retrieve rates for an open ticket: (Note: Perot has six engines it uses to get rates for various 

If] products. The Rate engine for Vehicle, the Charge engine for estimating and allocating charges, 

0 the Equipment engine for ancillary items such as child seat and ski rack, the Coverage engine for 

h h insurance coverages, the Ancillary engine for add on fees such as youthful driver and additional 

driver and the General conditions engine for providing messages and standard conditions.) 


• The pickup group and branch 

• The pickup date 

• The pickup time 

• The return group and branch 

• The return date 

• The return time 

« The booking channel (reservation origin), 

• The rental status (ticket status - reservation, open, closed^ 

• The rate source (account number, account name or default type) 

• The rental type (insurance, body shop, dealership, eta) 

• The billing cycle 

Note: There needs to b e some wayfoat the user has the ability specify a start chargesdate 
and time that is different than the pick'-update and time. 
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Having values for ali of the above items wit! allow the system to retrieve either a single rate plan 
or display a ll multiple r ate plans to the user so they can choose which one to use. Once a single 
rate plan' has been selected, enter TO^ L§gj|g ^ n(: i the following information will allow the system 
to show a rate by product. 


• The specific unit (vehicle), either a direct entry or selection from a listing of available 
units. 

® The option to display the car cla^es^associated with the rate plan. 

• The coveraae(s) (as related to ca^ class) 


2.1.3 Pickup Group and Branch 

. Bv the time this use case i s invoked, th |^ ptem^houid have al readyde ^lted the pickup group 
and branch to the termin al locatio n group and branch 

2.1.4 Pickup date and time 

If the user has not entered a pickup dateana time, then the system will default the date and time 
to current The user can then have the ability to change jt 

2.1.5 Return Group and Branch 

The system should default the return groupjnd branch to the same asjhe pickup group and 
branch and allow the user to edit or chanoejhis, 

2.1.6 Return Date and Time 

The user is required to entered a re^m^^m6^^ 

2.1.7 Booking Channel - Re servation Origin 

. The reservation origin should be able to b extinguished by the system and have the approp jiate 
value assigned by the system, 

2.1.8 Rental Status 

For this use ca se the status will be 'QPM^JMJY§ tem should be able to determine thestatus 
and assign the appropriate value forjilMnsta^es of a rental transaction. 

2.1.9 Rate Source 

The user has either selected an account name or account number to locate and assign a rate 
source, or has selected to uselhe default rates . 

2.1.10 Rental Type 

The user Is required to select a rental Ivpe, 

2.1.11 Silling Cycle 

The user is required to select a billing cyd e. 

With the above information entered into the system, selected by the user, or determined by the 
system, the Perot engine should be able to return any and all associated rate plans with a 
particular account. 
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if there are multiple rate plans (agr eem ents), the system should display this information 
to the user, and proyide a way to selecl die appropriate one. Use case continues below. 

If there is a single rate plan ( agreenieuLL the area is populated with that plan textual 
description, • . 


2.1.12 Unit (Vehicle) Selection 

The system will allow the user to eithejientor a specific unit number or to have the ability to select 
one from iliit of availabje^unjts. 

2.1.13 Display all Car Classes for Rate PianoBtioa, 

The systemwill have a feature available which will allow theuser lo display all of thenar 
classes associate d with the specific rgrt£p jm^lected and the corxg§EQadiag u ,rates for each 
car class. 

Once the user hassefected a singj gjgpjl^g the system will display the units available for 
that car class. ^Y3^EL^£^ r selects ^^hicie (Unit), this use case eontmu^^ 

2.1.14 Get Rates 

Once a specific unit has been identified or selected by the user, there should be some 
mechanism to allow the user to specify^ne system to get the jates, 

2.1.15 System Returns Rates 

With all of the previously e ntered or system derived informat ion, the system determines by the 
specific unit, the rate and ca- class andjeiurns the rate for the vehicle and the appropriaterate 
for ail applicable coveraoesCDW, P^j^j ^SLP. 

The rate information is presented to the userbyproduct for daily, weekly, monthly and hourly time 
periods, if a rate is not available for itim ioenod, the system returns a value of zero, 

This informatio n is displa yed to the us erj^ ^ma nner that allows editing orcharding of the rates, 
Am^ only app jitp^this ^ecific rental transaction and will not be reflected 

back in theTate plan. 

. If the system cannot find_acar classjbggg yjg the unit, for that rate plan, the use case continues 
at Car Class Not Present in AccountRate Plan. 

2.1.16 User Accepts Rates Returned. 

. .. The system returns the rates for the time periods indicated for the vehicle, selected or indicated, 
and all available coveraggfL. COW, P^andJSL^^ accepts the rate without changes, 

informs the renter of the rateiTbv produci^and saves the transaction 

The user also has an option to bavgjthe^svstem to calculate total charges, for the selected 
products, "over the duration of thTrigMZltliswi I I invoke the estimated charges use case. 


The use case ends. 
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2.1.17 Car Class Not Present In Account Rate Pla n 

If the car class is not present in the account rate plan, the system notifies the user of this and 
gives the user the option of using defaulfrates, selecting a different car class within the specific 
rate plan, selecting another rate source or manually entering in the rates for the vehicle and/oF 
coverages. " 

If another rate source is selected, default o r another account, the use case resumes at 2.1 .9. 

If another car class is selected with in the specific rate plan, the use case resumes at 2.1 .13. 

If the user manually elects to manually enter the rates, there should be some function to allow 
this process. The rates will be saved with the rental transaction. 

This use case ends. 
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3. Special Requirements 

3.1 if any component of the information neetie/j for rate retrieval is changed which causes a change 
injhe rates for any item, a message is displayed to the user informing them of such, 

3.2 GPS Response Time 

Our contracts with GPS systems^^ a response be returned to a rate request within 

seven second s. 

4. Pre-conditions 

4.1 User must be logged on 

• The user is logged Into ECARS2^_2.0 application and ECARS 2.0 has validated the 
user has privileges to perform rateVerification. ~~ 

• The user has access to the local machine. 

• The user has access to the nefwofjc 

5. Post-Conditions 

5.1 < Post-condition One > 

6. Extension Points 

6.1 <Name of Extension Point> 

7. Questions - all answered in initial business review. 
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Business Use-Case Specification: Open Ticket Search 

1, Open Ticket Search 

1.1 Brief Description 

This use case will describe how a user interacts with a system to search for and locate an open 
ticket . It will show the flow of events that occur when a search is conducted to locate an open 
ticket. The system will search for and locate an open ticket (or more than one open ticket) based 
on the search criteria entered by a user. 


2. Flow of Events 

2.1 Basic Workflow 

2.1 .1 The use case begins when the user chooses to search for an open ticket. 

2.1.2 UC1.1.1 The system displays all search a'mna fields emptjed_oyt L allowing the user to enter 
specific search criteria (as can be seen in Tables A and B). UC1.1.2 This use case will default 
the group/branch location to the machine's, physical location. The user may choose to searchby 
one, two or three (three being the maximum) of these search criteria. The criteria does not 
include thegroup/hranch. ff a ticketjiumb e r^is entered as well as other criteriajhe systerrn^ji 
only search for the tjckehi umber and disr egard any other search ^criterja. 

2.1.3 TABLE A The user will most commonlyenier the following information: Jgenter last name Renter 
Phone number(s) Tickejj^g^^ current group bran^jocationalways displays 

2.1.4 T ABLE B Other criteria the user jg§^ai| ^ Unit number PO numb er , RO number, Claim 
number. (This is currenthTTn one fieldj^cgj£jt name (the user can search for a account na_me 
based on, bill-to, shop. Account number (same as Account name) Renter First Name (along with 
Renter LasUsfarne) Ticket Open Patten ^a[Veh icle License Plate Number Search by eithera 
single group/branch, or entire groujgJThjsjs the location that opened the contract.) Note^Jjhe 
current group branch iocatiog j^|ys dispjays. The user may search by either account name or 
number: not by both, 


2. 1.5 The use case continues with sub flows (Renter Last Name through Ticket Number ) for renter last 
name, renter home phone number, and ticket number (as shown in Table A). The use case can 
be read at any of these sub flows (a user is most likely to search by one of these criteria more 
often than the criteria identified in Table B). If the user chooses to search by criteria listed in 
Table B, the use case continues with the alternative workflows ( No Ticket Found through Rental 
Vehicle License Plate Number ). 


2.2 Renter Name-Sub Flow 

2.2.1 The user chooses to search for an open ticket by entering alphanumeric text in both the renter 
first and last name fields or lust the last name field,. 

2.2.2 The system searches for a match on the text, applying from left to right on the number of 
characteTsfor an open ticket by the entered renter name. (There is an implied wildcard at the 
end of the character set(s) entered but nc leading or imbedded wildcards within the character 
set(s).) 
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2.2.3 The system produces and displays the resul! 

: set if one or more tickets are found. 


2.2.4 If no open ticket(s) are found with the na me entered, continue to alternate flow No Ticket Found. 
If the user enters only a first name continue at alternate flow Renter First Name Only. 


2.2.5 The user selects to view the details of a single open ticket from the list and the use case ends at 
this point. 


2.3 Renter Phone Number-Sub Flow 

2.3.1 The user chooses to search for an open vigket by entering a renter phone number. (The number 
entered must be the full number includipglarea ^codaj 

2.3.2 The system searches for an open ticket with any matching renter phone number regardless of the 
. phone number type. (Match musTfae exact: no wildcard search.) 

2.3.3 The system produces and displays the result set if one or more tickets are found. 

2.3.4 If no open ticket(s) is found with the phone number entered, continue to alternate flow Nojjcket 
Found. 

2.3.5 The user selects to view the details of a single open ticket from the list and the use case ends at 
this point 


2.4 Ticket Number-Sub Flow 

2.4.1 The user chooses to search for an open ticket by entering a ticket number. 

2.4.2 The system searches for an open ticket with any matching ticket number. (Match must be exact: 
no wildcard search.) The system produces and displays the result set if one or more tickets ajre 
found. ~~ 

2.4.3 If no open ticket is found with the ticKet number entered, continue to alternate flow No Ticket 
Found"" 

2.4.4 The user selects to view the details of a single open ticket from the list and the use case ends at 
this point. 
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3. Alternative Workflows 

3.1 No Ticket Found 

3.1 .1 If no open ticket is found based on either !he last name, phone number, ticket number, unit 

number, FOTRO/Claim number, account rime, account number, ticket open elate and the location 
entered, the user can continue to 2,1 .STrTthe main flow or choose not to perform another search 
:. and the usecase ends. 

* 3.2 Renter First Name Only 

3.2.1 The user cannot search for an o pen tickejjby entering the renter 's firs t name and leaving the last 
name field blank. " 

3.2.2 The system will not allow the user to enter a first name unless a last name is present 

3.2.3 The use case ends and^continues ai thej|enfer Name sub flow. 

3.3 PQ/RO/CIalm Number 

3.3.1 The user chooses to search for an^per^ticket by entering either a PQ/RQ/Ciaim number. 

3.3.2 The system searches for a match gnt^gj|xt, applying from left to right on the number of 
characters for an open ticket by the enterajEO/RO/Claim number The system produces and 
displays the result set if one or more ticketsare found. 

3.3.3 If no openticket(s) are returned withjhe ente red PO/RO/Claim number the user can continue to 
alternate flow No Ticket Found. 

3.3.4 The user selects to view the details of a single open ticket from the list and the use case ends at 
this point. 

3.4 Unit Number 

3.4.1 The user chooses to search for aQjOBgnticket by entering a unit number. 

3.4.2 The system searches for an open ticket with any matching unit number. (Match must be exact 
no wildcard search.) The system producesand displays the result set if one or more tickets are 
found. 

3.4.3 If no open ticket is reti£nedjA^the enteredunit number, the user can continue to alternate flow 
~~ No TickefFound. 

3 A4Tbe system displays records found and the use case ends at this pointy 

3.5 Bifl-To/Shop Account Name Search 

3.5.1 The user chooses to search for an open ticket by entering alphanumeric text in the account name 
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field where the account could be the biil-to and/or the shop. 


3.5.2 The system searches for a match on the t g xt applying from left to right on the number of 

characters for an open ticket by the enter|j account name. (There is an implied wildcard at the 
end of the character set entered but no legging or imbedded wildcards within the character 
set.) The system produces and displays the result set if one or more tickets are found. 


3.5.3 If no open ticket is returned with the entered referral source customer, the user can continue to 
alternate low No Ticket Found. 

3.5.4 he user selects to view the details of a single open ticket from the list and the use case ends at 
this point. 


3.6 Account Number Search 

3.6.1 The userchooses to search for an open ticket by entering alphanumeric text in the account 
number field where the accounTcould be the bill-to and/or shop" 

3.6.2 The system searches for an open ticket by the entered account number. ( Match must be exact: 
no wildca T dsearch.) The sys tem prod u^j land displays the result sei j f one^Tnore" tickets are 
found. 

3.6.3 If no open ticket is returned with the entered account, the user can continue to alternate flow No 
Ticket Fou nd. ~~ " 

3.6.4 The user selects to view the details of a single open ticket from the list and the use case ends at 
this point. 


3.7 Ticket Open Date 

3.7.1 The user c.iooses to search for an opent l cket containing by entering the date that the ticket was 
opened . 

3.7.2 The system searcnes for an open ilcket b v the entered ticket opening da ta (Match must be 
exact: no wildcard search.) The system p roduces and displays the result set if one or more 
tickets are found." 

3.7.3 If no open ticket is returned with the entered ticket opening date, the user can continue to 
alternate flow No Ticket Found . 

3.7.4 When the user elects to search on a date for open contracts, the search will pull all contracts with 
an open contract date 1 day prior throug}^ specified date. 


3.7.5 The user selects to view the details of a single open ticket from the list and the use case ends at 
this point. 


3.8 Rental Vehicle License Piate Number 

3.8.1 The user chooses to search for an open ticket containing by entering rental vehicle license plate 
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number. 

3.8.2 The system searches for an open ticket by the entered entering rental vehicle license plate 
number. (Match must be exact: no wil dc a r d search.) The system produces and displays the 
result set if one or more tickets are founds 

3.8.3 If no open ticket is returned with the entered ticket opening date, the user can continue at 
alternate flow No Ticket Found . 

3.8.4 The user selects to view the details of a single open ticket from the list and the use case ends at 
this point. 


4. Special Requirements 

ml 4.1 The user must have the ability to sort within the table. 

U — 

!,'! 5. Pre-Conditions 

s s "is 

Cl 5.1 A user is authorized through a login process to access the panel that is necessary to search for open 
"*J tickets. 

: .. 3 
s : 

6. Post-Conditions 

111 

m 6.1 <Post-condition One> 
y 7. Extension Points 

i; s 

VJSfS 

7.1 <name of extension point> 
8. FAQ 

8.1 .1 All the current search parameters are based upon an "AND" relationship. Should the system give 
the user the option to search by an "OR" relationship? 

8.1.2 Answer: No 
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Use Case Specification: Vehicle/Shop 


1. Vehicle/Shop Use Case 

1.1 Brief Description 

This use case describes the how the user interacts with a system to indicate the renter's type of 
vehicle that is being repaired, notes about the vehicle, whether the vehicle is drivable, the type of 
loss, the date of loss and the theft waiver days. This use case also describes how the user 
interacts with a system to indicate which shop a renter's vehicle is being repaired at. 

2. Flow of Events 
2.1 Basic Flow 

2. 1. 1 Select Vehicle/Shop 

The Vehicle/Shop Use Case begins when the user n avigates to the Vehicle/Shop area of a 
reservation or ticket. Thiscould be initiated at any point during the Reservation/Open TicRet 
process. 

2. 1.2 System displays the Select Vehicle, Loss Information and Select Shop Areas 

The system displays an area for the user to select and enter information about the renters 
vehicle. The fields disp layed to the user are t he following:] 

• Year (If the physical terminal location is in the U.K. and Ireland the system does not display 
this field.) ~ ~ 

• Make 

• Other Make 

• Model 

• Other Model 

• Color 

• OTier Color 

• Registration Number (If the physical terminal location is in Europe the system displays this 
field. 

If the physical terminal location is in Germany the system also displays the follo wing field to the 
user. 

• Class 

5 = CL2 j 3, 4, 5, 6, 7, 8, 9,10) 

(The Legacy/ECARS 1 .0 system does not store the registration number or the "Schwackeliste" 
Class in Germany.) 

If the physical terminal location is in Germany also displays the following fields to the user; 

• Vehicle Type — "~ 

• Number ofDbors 

• Fuel Type 

• Engine Size 

• Engine Power 

• Class 


The system also displays an area for the user to enter and select loss information about the 
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vehicle. The fields displayed to the user are the following^ 

• Is Car Drivable?: 
o (Blank) 

o Yes 
o No 

• TypeTof Loss: 
o (Blank) 

o Damage 
o Tfi|Tf 

• Total Loss 
o (Blank) 
o Yes 

o No" 

• Dateof Loss 

• Theft Waiver Days (If the physical terminal location is in Europe the system does not dispjay 
this field.) 

o (Blank) 
o 1 Day 
o 2 Days 
o 3 Days 


The system also displays an area for t he user to enter Notes about the Vehicle. 
The default values for the above fields is (Blank) 

The system displays an area for the user to select an account from the Branch Short List The 
system also gives the user the option to: ~~ 

• Enter a Lega cy Custom er Number. If the user chooses this option, the use case continues 
alternate flow Enter a Legacy Customer Number. 

• Search for an Account. If the user selects this option, the use case continues at alternate 
flow SearcFT 

• Add a "Note" on File" Shop to the res ervation/op en ticket. If the user selects this optiqrythe 
use case continues at alternate flow Add Not on File Account. ~ 

2. 1.3 User Decides to Search for Year 

The user initiates a searc h for the y ear a renter's vehicle w as manufactured. 

2.1.4 System Searches for Vehicle Year 

The system retrieves and displays the list of years that a user may select from. = 

2.1.5 User Selects the Vehicle Year 

The user selects the year of the renter's vehicle. 

2.1.6 System Searches for Make 

The system retrieves and displays the list of possible make s to choo se from for t he previously 
selected (vehicle) year 

2.1.7 User Selects the Make 

The user selects the make of the renter's vehicle. The user can also choos e to select "Other" 
and/or enter text in the "Other Make" field. 
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2.1.8 System Searches for Model 

The system retrieves and di splays the li st of possible models to choose from for the previously 
selected make. 


2.1.9 User Selects the Model 

The user selects the model of the renter's vehicle. The user can also choose to select "Other 
aria enter text in the "Other Model" field. If the physical terminal location is in Germany, the use 
case continues at Alternate Flow German Vehicle and Class Information. 

2.170 System displays Colors 

The system retrieves and displays the list of colors to choose from. 

2.1.11 User Selects the Color 

The user selects the color of the renter's vehicle. The user can also choose to select "Other'Vand 
enter text in the "Other Color" field. 

2.1.12 User Enters the Vehicle Note 

The user enters a note about the renter's vehicle. 

2.1.13 User Selects and Enters the Loss Information 

The user selects whether the car is drivable, the type(s) of loss and the date of loss. If the user 
selects "Theft" as a type of loss the use case continues at alternate flow Theft Waiver Days . User 
Selects to display Branch Short List 

he user selects the optio n to displa y the branch short list. 

2.1.14 System displays Branch Short List 

The system retrieves and displays the Branch Short list. The columns that are dis played to the 
user are (from left to right). 

• Account name 

• Legacy CusTomer Number (called Account Number in ECARS 2.0) 

• Account type 

• Owning Group and Branch 

• Address 
CTg 
State 

• Zip- 

• Phone Number(s) 

If the physical terminal location is in Europe, the use case continues at Alternate Flow European 
Branch Short List. 

2.1.15 User selects Account from Branch Short List 

The user selects an account from the list. If the user does not choose an account from thejjst, 
the use case continues at alternate now SearcFT 

2. 1. 16 System Displays Contacts 

The system displays the list of Contacts for the selected Account to the user along with 
"Unknown". (All Accounts have a listing of "Unknown 7 ' as a Contact) 
The column displayed to the user will be the tojlowin^ 
• Last Name 
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• First Name 

If there are no Contacts identified for a particular Account besides "Unknown", the usecase 
continues at alternate flow No Contacts. 


2.1.17 Option to Select Contact or Add New Contact 

Th e user has the option to select a contact from the list or add a New Contact 

2.1.18 User Selects Contact 

The user selects a contact from the list. If the user chooses to add a new contact, the use case 
continues at alternate flow Add New Contact ~~ 

2. 1. 19 User Selects to Exit the Vehicle/Shop Area 

The user selects to exit the Vehicle Area/Shop. (From here, the user ca n navigate to any other 
area within the Reservation/Open Ticket) 

2.1.20 Validation of the Date of Loss and Theft Waiver Days 

The system validates the value in the date of loss field. If a date of loss is not valid because: 

• The date does not exist (February 30j 

• The date is greater than today's date, 

the use case continues at alternate flow Invalid Date Value. 


2.1.21 End 

The use case ends. 
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2.2 Alternative Flows 

2.2.1 German Ve hicle and Class Information 

2.2.1.1 The system retrieves an d displays t he list of Vehicle Types that a user may select from for the 
previously selected model. 

2.2.1.2 The user selects the Type of the renter's Vehicle 

2.2.1.3 The system retrieves and displays the list of Number of Doo rs that a us er may select from for the 
previously selected Vehicle Type7 

2.2.1.4 The user selects the Number of Doors for the renter's vehicle. 

2.2.1.5 The system retrieves an d displays the list of Fuels that a user may select from for the previously 
selected Number ot D oors tor t he renter's vehicle. 

2.2.1.6 The user selects the Fuel type for the renter's vehicle. 

2.2.1.7 The system retrieves and displays the list of Engine Sizes th at a user m ay select from for the 
previously s elected Fu el type for the renter's vehicle^ 

2.2.1.8 The user selects the Engine Size for the renter's vehicle. 

2.2.1.9 The system retrieves and displays the list of Engine Powers that a user may select from for the 
previously selectedEngine Size for the renter's vehicle? 

2.2.1.10 The user selects the Engine Power for the renter's vehicle. 

2.2.1.11 The system retrieves a nd displays the Class for the renter's vehicle. 

2.2.1.12 The use cas e continue s at System displays Colors in the basic flow. 

2.2.2 Theft Waiver Days 

2.2.2.1 When the user selects "Theft" as a type of loss, the system enables the "Theft Waiver Days" 
fielcT 

2.2.2.2 The user selects the number of theft waiver days. 

2.2.2.3 The use cas e returns to User Selects to Exit the Vehicle/Shop Area in the basic flow. 

2.2.3 Invalid Date Value 

2.2.3.1 The system displays a feedback message that the "Date is invalid". 

2.2.3.2 The system prompts the user to correct the date. 

2.2.3.3 The user se lects to cor rect the date and the us e case returns to User Selects and Enters the 
Loss Intormation in the basic flow. 
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2.2.4 European Branch Short List 

2.2.4.1 The system retrieves and displays the European Branch s hort list. (N OTE: This list is comprised 
of all accounts thathaye an owning Group that equals the Group ot the physical termina[ 
location.) The columns displayed to the userare : 

• Account Name 

• Account Number 

• Account Type 

• Owning Group/Branch 

• Address 

• City 

• State 

• Z£ 

• Phone Numbers. 

2.2.4.2 The user selects an account from the list that is displayed. 

2.2.4.3 The use case continues at User selects Account from Branch Short List in the basic flow. 


2.2.5 Search 

2.2.5.1 The system displays an a rea with a ll the fields emptied out so that the user can enter search 
cr i terja The f | e , ds tha t are ava j| a bi e are ; ~~~ 

~~ m Group. This includes a n "All Gro ups" option. For reservation pilot, group will 
limited to the physical location's group only. 

• Account Name ~~ 

• Account Phone Number(s) 

• Account Type. This includes an "All" option. (See Special Re quirements forthejist^ 
of valid Acc ount Types} ~~ 

2.2.5.2 The user enters an Account Name and selects "All" as the Account Type. 

2.2.5.3 The user initiates the search. 

2.2.5.4 The system validates th e search criteria. (If only an account type is entered, t he system wJH 
prompt the user that at least one othercriterion m ust be sele cted^ IfojTly a group is chosen, the 
systemwillp the user that at least one other criterion must be selected,} 

2.2.5.5 The system checks the s tatus of the search. If No Account Matches are found, the use case 
continues at alternate flow No Account Matches. 

2.2.5.6 The system displays the matches to the user in a summary list. The columns that are displayed 
to the user are: (from left to rightj 

• Account name 

• Legacy Customer Number (called Account Number in ECARS 2.0) 

• Account type 

• Owning Gr oup and Branch 

• Address 

• Cjf£ 

• State 

• zip- 

• Phone Number(s) 
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2.2.5.7 The user has the following options: 

• Select an account from the summary list. 

• Clear the search criteria. 

• Search agaTFT 

• Exit 

2.2.5.8 If the user chooses to select an account from the summary list, the use case continues at System 
Displays Contacts in the basic flow, jtth e user choose s to clear t he search criteria, the use^case 
continues at the firststepin alternateHbw Search. If the user chooses to search again, jhe iise 
case continues at the first step in alternate flow Se arch^ Ifth e user chooses to exit, the use case 
continues at System displays Branch Short List in the basic flow^ 

2.2.6 Enter a Legacy Customer Number 

2.2.6.1 From the Basic Flow, the user chooses to enter a Legacy C ustomer Number 

2.2.6.2 The user types in aLegacy Customer Number and initiates a search for all the information 
associated with the entered Legacy Customer Number. 

2.2.6.3 The system checks the sta tus of the search. If No Account Matches are found, the use case 
continues at alternate flow No Account Matches. If More than one Account match is found, the 
use case continues at alte rnate flow More Than One Accoun ^MgtcK It the search results in only 
one match, the use case continues at S ystem Displ ays Contacts in the bastoftoy^ 

2.2.7 No Accoun t Matches 

2.2.7.1 From the basic flow, the system dis plays a message to the user letting them know that No 
Account Matches or records were found. — ~ 

2.2.7.2 The use case continues at System displays the Select Vehicle, Loss Inform ation and Select 
Shop Areas in the Basic Flow. 

2.2.8 More Than One Acco unt Match 

2.2.8.1 The system displays a summary list of the matches to the user. The columns that will be 
displayed in the summa ry list are (from left to rigTigr 

• Account name 

• Legacy Customer Number 

• Account type ~ 

• Address 

• Cjty 

• State 

• Zip 

• Phone Number(s) 

2.2.8.2 The user has the option to select an account fr om the list or to exit. If the user selects an 
Accountfrom the list, the use case continues at System Disp lays contacts in the basic flow. If 
the user choos es to exit the list without s electing an Account, the use case co ntinues at System 
displays Branch Short List in the basic flow. 


Confidential 


©<Company Name>, 2000 


Page 13 


<Project Name> 

Version: <1.0> 

Use Case Specification: <Use-Case Name> 

Date: <dd/mrnm/yy> 

<document identified 


2.2.9 Add Not on File Account 

2.2.9.1 The system displaysan a rea for th e user to enter Account information for an account that isjriot 
Qn fj|e Jhe fje | ds that must be enterec j are: 

• (Account) Name 

• (Street) Address 

• m 

• Phone Number 

• Crty 

• State 

• Contact Last Name 

• Contact First Name 

The user enters the (Account) Name, (Street) Address, Zip/Postal Code and Phone Number. 

The system displays the option to search for the City and State/Province based upon the 
Zip/Postal Code and Country. 

The user selects the option and the system performs the sea rch for the City and State/Province 
that match the Zip/Postal Code and Country. ~~ 

The system produces a single City and State/Province result and continues at the next step in 
the basic flow. If the search produces no matching City and State/Province intormation, the use 
case continues at alternate flow No Match to Zip/Postal Code . If the search produces multiple 
cities the use case continues at alternate flow Multiple City Results. 

The system populates the City and State/Province fields. The system also makes the information 
in these fields available for edit. 

The system associates the Not on F ile accoun t to the reservation/ticket and the use case 
continues at alternate flow Add New C ontact Itthe user chooses to exit, the use case continues 
at System Displays Contacts in the basic flow\ 

The system associates the new contact added to the Account chosen and the use case 
continues at User Selects to Exit the Vehicle/Shop Area in the basic flow. 

No Match to Zip/Postal Code 

2.2.10.1 The system displays a feedback message that the zip/po stal code does not produce matching 
city and sta te/provin ce information? 

2.2.10.2 The system prompts t he user to manually enter city and state/province information. 

2.2.10.3 The user se lects to ma nually enter city and state /province i nformation and the use case 
proceeds back to 2.2.9.7 in the alternate flow Add Not on File Account. 

2.2.11 Multiple City Results 

2.2.11.1 The system displays a feedback message that t he Zip/Postal code prod uces more than one 
matching city. 

2.2.11.2 The system displays the list of cities and prompts the user to select a Cit^ 

2.2.11.3 The user selects a City from the list and the use case proceeds back to 2.2.9.7 in the alternate 


2.2.9.2 
2.2.9.3 


m \ 

O 

ill 
m 


2.2.9.4 
2.2.9.5 


i; : ; 


2.2.9.6 


111 2.2.9.7 


O! 

o 


2.2.9.8 


2.2.10 
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flow Add Not on File Account. 


2.2.12 No Contacts 

2.2.12.1 From the basic flow, the system displays a message letting the user know that no contacts have 
been set up for this Acco unt. (AILAc counts have a listing of "U nknown" a s a contact 7M 
message will displaywhen "Unknown" is the only contact present.) 

2.2.12.2 The user can either: 

• Add a new contact. 

• Select a contact of "Unknown" 
• 

2.2.12.3 If the user chooses to add a new contact, the use case continues at alternate flow Add New 
Contact . If the user selects a contact of "Unknown", the use case continues at User Selects to 
Exit the Vehicle/Shop Area in the Basic Flow. 

2.2.13 Add New Contact 

2.2.13.1 From the basic flow, the s ystem dis plays an area for the user to enter C ontact information. The 
f i ejds that must be en tered are: 

• Last Name 
And/or 

• First Name 

2.2.13.2 The user enters a first and/or last name and accepts the new contact information entered^ If 
the user chooses to exit, the use case continues at System Displays Contacts in the basic flow. 

2.2.13.3 The system associates the new contact added to the Account chosen and the use case 
continues at User Selects to Exit the R enter's Vehicle/Shop Area in the basic now. 

3. Special Requirements -Vehicle/Shop Use Case 

1) Year, Make and Model domain values come from the database. 

2) The list of years that the renter's vehicle was manufactured wflfbe listed in descending 
order. 

3) Tfienote entered into the Vehicle Notes field should be viewable from the Vehicle Notes 
section of the Vehicle/Shop screen. They WILL NOT be viewable from the Notes screen/use 
case.. 

4) TTcontact must be selected for every Account that is select as a Shop. NOTE: T his is a not a 
requirement for a reservation only open ticket 

5) The valid Account Types that are displayed to the user in Search are^ 
_ Bo(jy Shop - 

o Corporate " 
o Government 
o Fleet 
o Dealership 
o Insurance " 
o Other 

6) The Branch Short List is currently being generated from the existing L egacy systemjmd 
is beingstored in a table on the Oracle database 

7) The system should not search or display for any deactivated or deleted accounts : 
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8) The user must have the ability to cancel a search at any time during the search. 

9) The Navigation Bar for the Vehicle/Shop area should display the following: 

a. Line 1 : Year, Make and Model of the Renter's Vehicle 

b. Line 2: Shop Account Name 

10) Notes should be generated when any of the following events occur 


The user adds a 
"Not on File" 
contact. 

Not on file contact "First Name Last 
Name" was added for Account 
"XXXXX" 

Create/Edit 

Create (if data exists from 

thp rpsprvation^ /Edit 

Vehicle/Shop 

The user changes 
the shop account. 

Shop "XXXX" was changed to 
"XXXX". 

Edit 

Create (if data exists from 
the reservation) /Edit 

Vehicle/Shop 

The user changes 
the type of loss. 

Type of loss "XXXX" was changed 
to "XXXX". 

Edit 

Create (if data exists from 
the reservation) /Edit 

Vehicle/Shop 

The user changes 
the "Total Loss?" 

Total Loss "XXXX" was changed to 
"XXXX". 

toit 

Create (if data exists from 
the reservation) /Edit 


Tfie user changes 
trie? date of loss. 

Date of loss "XXXXXX" was 
changed to "XXXXXX". 

Edit 

Create (if data exists from 
the reservation) /Edit 

Vehicle/Shop 

TBe user changes 
number of theft 
w&iver days. 

Theft waiver days "X" was changed 
to "X" 

Edit 

Create (if data exists from 
the reservation) /Edit 

Vehicle/Shop 

TSe user changes 
thtel renter's vehicle 
Y&ar. 

The renter's vehicle Year "XXXX" 
was changed to Year "XXXX". 

Edit 

Edit 

Vehicle/Shop 

The user changes 
the. renter's vehicle 
M&ke. 

The renter's vehicle Make "XXXX" 
was changed to Make "XXXX" 

Edit 

Edit 

Vehicle/Shop 

Ttlf user changes 
thfirenter's vehicle 
Model. 

The renter's vehicle Model "XXXX" 
was changed to Model "XXXX" 

Edit 

Edit 

Vehicle/Shop 

The user changes 
the renter's vehicle 
Other Make text. 

The renter's vehicle other Make 
"XXXX" was changed to "XXXX" 

Edit 

Edit 

Vehicle/Shop 

The user changes 
the renter's vehicle 
Other Model text. 

The renter's vehicle other Model 
"XXXX" was changed to "XXXX" 

Edit 

Edit 

Vehicle/Shop 

The user changes 
the registration 
number of the 
renter's vehicle. (If 
the physical 
terminal location is 
in Europe. 

The renter's vehicle registration 
number was "XXXX" was changed 
to "XXXX". 

Edit 

Edit 

Vehicle/Shop 

The user changes 
the class of the 
renter's vehicle, Xlf 
the physical 
terminal location is 
in Europe.) 

The renter's vehicle class "X" was 
changed to "X". 

Edit 

Edit 

Vehicle/Shop 
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Edit Reservation 
Shop Area Fields 
Account Name 

If the account name is changed (to a valid account), account number will change 
appropriately and the contact name will now be "select". 

Account Number 

If the account n umber is c hanged, the account name will chan ge approp riately and the 
contact name will now Pe "select". 

Contact Name 

There are no edit rules for open ticket on changing or deleting a contact nanne^ 
Phone Number 

There are no edit rules for open ticket on changing or deletin g a phone number. 

Vehicle Area Fields 

Year 

There are no edit rules for o pen ticket on changing or deleting a Year. 
Make 

If a Make is changed or deleted, the Model field will be cleared. 
Model 

There are no edit rules for open ticket on changing or deleting a Model. 
Other Make, Other Model, Other Color 

There are no edit rules for open ticket on changing or deleting an Other Make, Other Model, 
Other Color. " 

Loss Information Area Fields 

Is Car Drivable?, Type of Loss, Total Loss?, Date of Loss, and Theft Waiver Days 

There are no edit rules for open ticket on changing or deleting Is Car Drivable?, Type of Loss, 
Total Loss?, Date ot Loss, and l nett waiver uayg: ~~ 

4. Pre-Conditions 

• A user is authorized through a login process to create or edit a reservation or ticket. 

• The user has accessed a reservation or ticket, either in the process of editing or creating. 

5. Post-Conditions 

6. Questions 
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2. OK/Exit renamed to "Save" 

David Beebe 




3. Selection of the Save option does 
not provide a feedback message to 
make sure they want to do that. 





4. Moved validation of date to after 
the "Save" step. (In HTML, Date 
Validation occurs after form submittal.) 
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following fields: 
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employee that verified insurance 
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fields. 

4. Removed Special Requirement that 
Employee Number field is available 
for edit. 
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Use Case Specification: Enter Renter's/Additional 

Driver's Insurance Information 


1- Enter Renter's/Additional Driver's InsuranceMQOII^ion Use Case 

1.1 Brief Description 

This use case will describe the interaction that occurs between a user and the system when the 
user inputs and selects details pertaining to the insurance information about a person who is a 
renter or additional driver. 

2. Flow of Events 

2.1 Basic Row 

2. 1. 1 Insurance Detail Area 

The Enter Renter's/Additional Drjvei^jrsuraiice Information Use Case begins whenjhe 
system displays the are^ of insurance information about the person who 

Is a renteroradditional driver, TTigJieldsjnJti^^ 

Information about the Insurance Company 

* C arrier 

* Agent 

• Phone Number 

« Namft of Ins urance Company Contact 

« Ppficv Number 

« Expiration Date 

information about the renxefs or the j^jljgML^ElJ Siy^^ 

• Comprehensive Deductible 

• Collision Deductible 

* Liability? 
o (Blank) 
o Yes 

o Mg 

• Assigned Risk? 
o (Blank) 

o Yes 

o Jig 

* Ljenholder Policy? 

o " IglankT _ 
o Yes 
o No 


2.1.2 Option to Cancel I Exit 

The system disoiavs the option for the user to Cancel/Exit. At any point during the entry of 
insurance information the u ser could decide to cancel ouTof the en try process at which time the 
use case would continue at alternate flow Cancel/JDdl 
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2.1.3 Option to Save 

The system displays the option toJSave , At any point during the entry of insurance information 
the user could decide to Save at which "time the use case would continue at basic flow Sava, 


2. 1.4 Company and Insurance Detail Information Area Entry 

The user can enter information in the following fields: the name of the Carrier, the name of the 
Agent, Phone Number, Insurance Company Contact, Policy Number, Expiration Date, the 
Collision Deductible amount and the Comprehensive Deductible amount. The user can also 
select the available choices for Liability, Assigned Risk, and Lienholder Policy. There are no 
default values for any of the above fields. 

215 Select Save Option 

The user selects the option to Save. 

2 1.6 Validation of Date 

The system validates the value in the Expiration Date field. If the Date value is not valid 
because it does not exist (for example 02/30/02) the use case continues at alternate flow 
Invalid Date . If the Date value is not valid because the Expiration Date is prior to the current 
date the use case continues at alternate flow Expired Policy Date . 

2. 1 7 Validation of Information Entry 

The system validates that if informa jgajjnii red in any one of the following fieids T that all of 
the otherfields listed also have informaTion entered in thenr 
5 Camef " 

• insurance Company Contact 
© Policy Number 

• Expiration Date 

• Collision Deductible 

• Comprehensive Deductible 

• Liability: Ye s/No 

If thesystem determines that any of the above fields are missing information, the system wl 
bresentthe user with a feedback mjjsaqe as to what fields are not filled to complete 
'Insurance Information. The systenjMLdMBlgy the option for the user to proceed _backto 
Company and Insurancepetail Information Area Entry in the basic flow to complete entry, 

2.1.8 Save 

The system saves all the information entered and selected in the fields of the of this usecase 
flow . This would be: 

• Carrier 

• Agent 

• Phone Number 

• Insurance Company Contact 
0 Wicv Number 

• Expiration Date 

• Comprehensive Deductible 

• Collision Deductible 

• Liability?: (BlankVYes. No 
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• Assigned Risk?: (BlanKl^gl^N g 

• Lienholder Policy?: (Blank).Yes, No 


2.1.9 End 

The Use Case ends. 

2.2 Alternative Flows 

2.2.1 Cancel/ Exi t 

2.2.1 .1 The user selects the option to Cancel / Exit. 

2.2.1.2 The system displays a f eedback messas^amjng that the insurance data will be lostjQhe 
user select s to Cancel / Exit. 

2.2.1 .3 T he svs:e m displays thejMoMQg. oMifffjll 

• Yes: to exit and lose data. 

• Ncr (elum to the use caie. 

(Theltefault option vviil be No: return to the use case.) 

2.2.1 .4 The user selects Yes the use case ends. If the user selects No, then continue in basic flow at 
the point where the user selected to Cancel / Exit. 

2.2.2 Invalid Date 

2.2.2.1 The system displays a f eedback messagejhMJ]^^ 

2.2.2.2 The system prompts the user to corred_the^Dg^ that Is invalid. 

2.2.2.3 The user selects to correct the Date and the use case proceeds back to Company and 
Insurance Detail Information Area Entry in the basic flow. 


2.2.3 Exprod Po ^gx^^ 

2.2.3.1 The system displays a f eedback message that the policy hasexgjred, 

2.2.3.2 T he system prompts th e user to : 

0 Cojiectihe policy e x piration data 

• j^iy^ Entry process, 

2.2.3.3 If the user selects to change the expiration date the use case proceeds back to Company and 
Insurance Detail information Area Entry in the basic flow, if the user selects to exit the open 
ticket process the use case continues at alternate flow Cancel / Exit. 

3. Special Requirements 

4. Pre-Conditions 

A user is already authorized through a login process to access the panel that is necessary to: 

• Create or edit a reservation. 
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• Open, edit or close a rental ticket. 


5. Post-Conditions 

6. Extension Points 

7. Questions 

Question: In the Employee Approval of the Renter's Insurance Information area should there 

be further security? (for example: update code). Or can the user just input the employee 

number and have the system save it as long as it is a valid employee? 

Answer: No further security is needed. The employee number information will be automatically 

populated into the correct field. This field is display only and the information in it cannot be 

changed. 

Question: What European requirements are there? 

Answer: Jon Jouris has indicated there could be translations for the U.K., Germany etc. Fields 
could be eliminated or labels could changed. 

As of 06/06/2001 an electronic copy of this document had been sent to Jon Jouris so that he 
can pass it on to the appropriate European personnel for feedback. 
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Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the Notes screen. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 

2. Reservation Notes Screens 


Notes - Microsoft internet Explorer provided by Enterprise Rent-a-Car 


File Edit View Favorites Tools Help 



Driver summary 1 
Driver summary 2 



ALL 



3 (ALL 


BaWl 


IBB 

- — — 

aiPfe 

m — p 


07/03/2001 Car is at Joe's Garage 
3:22PM 


CLOSE CALLBACK ECARS 2.0 
USER 


jDates summary 1 
jDates summary 2 


a*: 



Figure 1 - Notes 
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31 Add Note - Microsoft Internet EHplorer pro. 



Notei 



Figure 2 - Add Note 
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X 



3 View Note - Microsoft Internet Explorer provided by Enterprise Rent a-Car 


V* i g V 1 / i\io tc^ ; 


Date: 7/02/2001 2s 22PM 
Status: Open 
Type: System 
Created By: System 
Arms Msg: Sent 

Note: ______ 

Does not like red cars. This shows the first two lines of the 
notes section. (2 @ 45 char) 



Figure 3 - View Note 


The text area shown here is big enough to show 
the entire database field without scrolling. 


Pi 


mm 


it 
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<fj Notes List - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 




Projects\HTML\OpenTicket\Notes\NotesListhtml| 


Notes List 


Contract: 411781 
Renter: Joe Smith 
Date: 07/09/2001 



Note 

Status 

Note Type 

Created By 

ARMS Msg . 

07/01/2001 
1:22PM 

Reservation Created 

Res 

System 

System 

Sent 

07/02/2001 
2; 22PM 

Does not like red cars. This shows the first two lines of the 
notes section.(2 @ 45 char) 

Open 

System 

System 

Sent 

07/03/2001 
3i22PM 

Car is at Joe's Garage 

Close 

Callback 

ECARS 2.0 User 



Records Found: 3 



3. 

3.1 

3.1.1 


3.1.2 


Figure 4 - Print All Records 


Reservation Notes Screen 

Reservation Number 

Behavior 

This area shows the uniqu e reservatio n number that has been assigned to the n ewly created reservation. 
The reservation number is 6 alphanumeric characters long. 1 another reservatio n is open, it reservation 
number will be displayed in thisarea as well. Th e user will have the ability to have up to 3 reservations 
open at a time. A hyperlink willbea vailabie on t he reservation numbers of the reservat ions that are NOT 
currently being displayed. For the reserv ation that is cu rrently displayed, the reservation number will not 
have a hyperlink available. This is to a llow the use r to navigate between the o pen reservations. 

Validation 

None identified at this time. 


3.1.3 Business Exceptions 

If the user tries to open a 4 th reservation, the system will display a message stating, "A maximumof3 
reservations may be displayed. fr ~ 
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3. 1.4 Systems Exceptions 

None identified at this time. 


3.2 Notes Title Bar Area 

3.2.1 Behavior 

The open area in the Notes Title Bar will allow the user to access transaction-wide functions. These 
liErtlons for Reserva tion are: ~ Options -, Print, V oid and Transfer. The delault option is "—Options - 
The user must press the Go button to initiate the selected function. 

The Title Bar Button area in the Notes Title Bar contains two buttons - a Go butto n and a Close button^ 

The Go button is always active, and is used to initia te a functio n selected in t he Options area. If the 
selected option is "—Options nothing should happen. 

The Close button is always active, and is us ed to close the current transaction. Th e button is labele^yjfa 
anTX' . Pressing this buttonwill cause a con firmation popup, asking the user if they wish to cancel fee 
miStion^riaTo^ all changes. If the user selec ts 'No 7 , they are returned to the same screen. Iffeguser 
ielects 'YesVjfae transaction isclosed with no changes saved to the database. 

3.2.2 Validation 

None identified at this time. 

3. 2. 3 Business Exceptions 
None identified at this time. 

3.2.4 System Exceptions 
None identified at this time. 

3.3 Button Line Area 

3.3.1 Behavior 

The Previous button will tak e the user to the Notes scr een within the same transaction. 
The Next button will take the user to the Referral screen w ithin the sam e transaction. 

The Complete button will initiate a save of the transaction AH validations will be performed returning any 
err ors to the user . If there are no errors, th e transactio n will be save4 , and the use r is returned to the 
Reservation Home Page. 

3.3.2 Validations 

None identified at this time. 

3. 3. 3 Business Exceptions 
None identified at this time. 

3. 3. 4 System Exceptions 
None identified at this time. 

3-4 Type 

3.4. 1 Behavior 

This is a drop down field containing the following domain values; 
• — All - 


Confidential 


©<Company Name>, 2000 


Page 9 


<Project Name> 

Version: <1.5> 

Supplementary Specification 

Date: <dd/rmnrn/yy> 

<document identifier^ 


• Bill To 

• Callback 

• Manual 

• Renter 

• Reservation 

• Shop 

• System 

The default value is "All". The summary list is filtered by the item selected from the values list The 
Status drop down list should be taken into consideration when filtering the surrmiar^list 

3.4.2 Validation 

No validation is necessary. 

3. 4. 3 Business Exceptions 

None have been identified at this time. 

3 .4 .4 System Exceptions 

None have been identified at this time. 

3.5 Status 

3.5.1 Behavior 

This is a drop down field containing the following domain values; 
S-~Ag 

• Reservation 

• Open 

• Close 

The default value is "AlTTThe s ummary list i s filtered by the item selected from the val ues list. The Type 
drop down list should be takeninto consideration when filtering the summary list. " 

3.5.2 Validation 

No validation is necessary. 

3. 5. 3 Business Exceptions 

None have been identified at this time. 

3. 5. 4 System Exceptions 

None have been identified at this time. 

3.6 Summary List 

3.6.1 Behavior 

The result list, as describe in the use case, will have a static column display sequence. All 
columns need to have the ca pability to b e sorted, asc ending and descending The user selectsa 
Contract by clicking onthehy perlink associated with the desired data row. I he s ummary list w iF 
be populated with the lates t note appearing first and the earliest no te appearing last (descending 
order sorted by date/tinned 

ftrvellipse (...) shouIrJ5eplaced at the end of the note text field if the verbiage contained in the 
note exceeds 8U characters. ~ 

Trie user must have the a"ppropriate security to view/edit the contract selected. 
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This list contains the application standard for lists regarding sorting by column. 

TTie 'ARMS Msg' column header does not directly translate for Germany; rather, it is 'ARMS'. 

3.6.2 Validation 

None have been identified at this time. 


3. 6. 3 Business Exceptions 

None have been identified at this time. 

3. 6.4 System Exceptions 

None have been identified at this time. 

3.7 Button Line Area 

3.7.1 Print AH Records button 
3.7 A A Behavior 

The Print All Records button will essentially generate an html report and send it to the printer. This will 
allow the user to print the entire collection of notes associated with a contract. This report will not be sent 
to the screen, it will only be sent to the printer. ~ 

3.7.1.2 Validation 

No validation is necessary. 

3.7.1.3 Business Exceptions 

None have been identified at this time. 

3.7.1.4 System Exceptions 

None have been identified at this time. 

3.7.2 Add Note button 

3.7.2.1 Behavior 

The Add Note button will display the Add Note screen for data input. 

3.7.2.2 Validation 

No validation is necessary. 

3.7.2.3 Business Exceptions 

None have been identified at this time. 

3.7.2.4 System Exceptions 

None have been identified at this time. 

4. Add Note Screen 

4.1 Note 

4.1.1 Behavior 

This is a free form text field in which the user may enter data. 
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4.1.2 Validation 

There must be data present in order for the note to be saved. 


4. 1.3 Business Exceptions 

None have been identified at this time. 

4.1 A System Exceptions 

None have been identified at this time. 

4.2 Button Line Area - Add Note 

4.2.1 OK button 

4.2.1.1 Behavior 

If data is not present in the Notes text field the feedback message reads, "Please enter a Note if selecting to 
Save/' Two options are presented, OK and Cancel. Ok will take the user back to the Add Note screen foF 
data entry. Cancel will dismiss the Add Note screen. ~ ~~ 

Ok will be the default selection. 

The application saves the Date/Time, Status, Type, Note text and Created By data at the time the note is 
committed to the database. 

Type — Manual 

Status = contract status as of note creation 

4.2.1.2 Validation 

There must be data present in the Notes text field. 

4.2.1.3 Business Exceptions 

None have been identified at this time. 

4.2.1.4 System Exceptions 

None have been identified at this time. 

4.2.2 Cancel button 

4.2.2.1 Behavior 

This button will dismiss the Add Note screen without saving any data. 

4.2.2.2 Validation 

If data has been entered the following feedback message is displayed; "Are you sure you want to exit and 
lose the entered information?". Two options are presented, Yes and No. Yes will dismiss the screen and 
not save the data, No will take the user back to the Add Note screen^ 

The default button selection is "No". 

4.2.2.3 Business Exceptions 

None have been identified at this time. 

4.2.2.4 System Exceptions 

None have been identified at this time. 
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5. View Note Screen 

This is a read only screen. 

5.1 Data 

5.11 Behavior 

This is a listing of the values associated with the selected note, this includes; 
- pate/rime 

• Status 

• Type" 

• Created By 

• Arms Message Status 

• Note text 

The Note text field should be large enough to display fee entire 510 characters as defined in the database. 

5.1.2 Validation 

No validation is necessary. 

5.1.3 Business Exceptions 

None have been identified at this time. 

5.1.4 System Exceptions 

None have been identified at this time. 

5.2 Button Line Area - View Note 

5.2.1 Print button 

5.2.1.1 Behavior 

This button will essentially print a screen print of the View Note screen. 

5.2.1.2 Validation 

There must be data present in the Notes text field, 

5.2.1.3 Business Exceptions 

None have been identified at this time. 

5.2.1.4 System Exceptions 

None have been identified at this time. 

5.2.2 Close button 

5.2.2.1 Behavior 

This button will dismiss the View Note screen. 

5.2.2.2 Validation 

None have been identified at this time. 

5.2.2.3 Business Exceptions 

None have been identified at this time. 
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5.2.2.4 System Exceptions 

None have been identified at this time. 


6. Rules 

6.1 Required Fields 

The Note text field is required for creating a note. Feedback messages will be presented, as defined 
previously in this document, when attempting to save a note without the requned lntormation. 

6.2 Saving 

A note must be defined before the data can be saved to the database. 

7. Security 

The user must have the appropriate security level to access this screen. 
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Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the Open Ticket Search screen, 
and its related screens. 


The system must be abl e to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 



Figure 1 - Initial Entry - Simple Search 
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'3 Enterprise* ECARS Application - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 


doV. ! ■::lQ*W$cte: Calibans . 


Open Ticket Search 



Figure 2 - Simple Search with Search Results 
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(Open Ticket Search m 

1 Group: 


Branch: 


Simple Search M 

S| ALL 


1 Iall 



Ticket Number: 


RO/PO/Claim Number: 


Renter Last Name: 


Unit Number: 


Renter First Name: 


Unit Plate Number: 


© Bill-To/Shop Name O Bill-To/Shop Number 


Renter Telephone Number: 


Open Ticket Date: 



Figure 3 - Advanced Search 
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Reservation Contracts Callbacks Rates 


Tools Help 


H Enterprise* ECARS Application - Microsoft Internet Explorer provided bj ^^^^jgg^ jg" 1 ^ j a J^ 


Open Ticket Search 



Group: 


Branch: 


1 01 -ST LOUIS 


LADUE RENTAL 01 01 


Simple Search 


jRO/PO/Claim Number: 


Ticket Number: 


Renter Last Name: 

|a_ Z. 

Unit Number: 


Renter First Name: 


Unit Plate Number: 


Renter Telephone Number: 


Open Ticket Date: 


® Bill-To/Shop Name O Bill-To/Shop Number 



"« Beatrice' arewwsi 


30622C3G6WXH3WSSURLZV04 


02/03/2001 A ^ffJ5Jf s I i!?" 3HXW6G j 


S 0101 2022543525 


30622C8G6WXH3WSSURL2V04 


0101 


AQUILINO, 
BEATRICE 


2022543525 


30622C8G6WXH3WSSURLZY04 


02/03/2001 A sx S [p^ff " 3HXW6H % 
02/03/2001 ^^oLJIS 1 ** 5 " 3HXW61 



Items 1 - 3 of 3 found 


First Prev 1 Next Last 


Figure 4 - Advanced Search with Search Results 
July 2001 


-l 


+ i 
mon 



Figure 5 - Calendar selection 


3. Group 

3.1 Behavior 

This search criterion will be limited to active rental The selection of "All" isjriso 

included, and will appear at the tot), or first in thejist . This search criteria area will be a 
drop-down box. The users would also like to have the ability to type a character, alpha or 
numeric, into the criteria area and have the drop down list position to the character. (If 
the user enters an "H" the drop down list would position to the first string beginning with 
"H" in the list) The default item should be the group associated to the terminal locale . 
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3.2 Validation 

The items appearing in the list are static; the user cannot add items to the list 
dynamically. 

3.3 Business Exceptions 

The user should not be allowed to view or select a group outside of security parameters. 

3.4 System Exceptions 

None identified at this time. 

4. Branch 

4.1 Behavior 

This search criterion will be limited to active branches The selection o f "All" is also included and will 
a ppear at the ton, or first in thejist This search criteria area will be a drop-down box. The users would 
^Tlike to have the ability to type "a character, alpha or numeric, i nto the criteria area and have the drop 
down list position t o the character , (If the user enters an "H" the drop down list would position to the first 
string beginning with "H" in the list) 

The default item should be the branch associated to the terminal locale . Branch items a ppearing in the list 
^HTl be hmited to the Group ite m selected. Once the selected Group item has changed the first item (AH) 
will be the default selection item. 

4.2 Validation 

The items appearing in the list are static; the user cannot add items to the list 
dynamically. 

4.3 Business Exceptions 

The user should not be allowed to view or select a branch outside of security parameters. 

4.4 System Exceptions 

None identified at this time. 

5. Ticket Number 

5.1 Behavior 

This search area will be an alphanumeric field. It will return exact matches for the characters entered . 
When this search criterion is used, any other entered criteria will be ign ored bv the system. Alphanumeric 
values will be accepted into thisjjeld. 

5.2 Validation 

None identified at this time. 

5.3 Business Exceptions 

None identified at this time. 

5.4 System Exceptions 

None identified at this time. 

6. Renter Name Last / First 
6.1 Behavior 

This search criteria area will be an text field containing an implied wildcard after the entered criteria . The 
First Name field will not be enabled until search criteria has been entered into the Last Name field. Thus, 
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the First Name field will not be accessible via either the tab key or the mouse unless Last Name data is 
present. 

It should be noted that either Last Name or Last Name and First Name used m 
combination, is considered to be just one search criteria. 

It will return exact matches for the characters entered and will continue with other text 
strings that match the characters entered, but are of a longer length (an implied wildcard). 
Example: If the Last Name search criteria entered were "Smith", you would receive back 
every open ticket with "Smith" in the Last name. You would also receive every character 
string that matched "Smith" for the first 5 characters, but was longer than five characters. 
Given this, you would also receive, "Smither", "Smithson", "Smithy", etc. These longer 
character matches would be alphabetically ascending after the exact character matches of 
equal length. The First Name field behaves in the same manner. 

6.2 Validation 

None identified at this time. 

6.3 Business Exceptions 

None identified at this time. 

6.4 System Exceptions 

None identified at this time. 

7. Ren ter Telephone Number 

7.1 Behavior 

This search criteria area will be an alphanumeric field It will not b e formatted for presentation purposes. 
R^Trns exact match es for the characters entered . A phone number is considered to be the entire number 
including area code. Example: In the United States, it would be the 3 digit area code, plus the seven digit 
phone number. (Country Code is not considered a part of the phone number.) The search will be on all 
phone number fields associated with the Driver/Renter. Curr ently, these are Home, Offic e and Other. 

7.2 Validation 

None identified at this time. 

7.3 Business Exceptions 

None identified at this time, 

7.4 System Exceptions 

None identified at this time. 

8. RO/PO/Claim Number 

8.1 Behavior 

— This search criteria area will be an alphanumeric field. 
Returns exa ct matches for the characters entered . 

8.2 Validation 

None identified at this time. 

8.3 Business Exceptions 

None identified at this time. 
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8.4 System Exceptions 

None identified at this time, 

9. Unit Number 


9.1 Behavior 

This search criteria area will be an alphanumeric field. 
Returns exact matches for the characters entered . 

9.2 Validation 

None identified at this time. 

9.3 Business Exceptions 

None identified at this time. 

9.4 System Exceptions 

None identified at this time. 

10. Open Ticket Date 

10.1 Behavior 

Only numeric values will be accepted into these areas. The search to the database will be 
an exact numeric, time stamp match . Associated with this field, is a calendar function 
that allows the user to select a date from a calendar screen, or similar feature, instead of 
entering a value (Figure 5 - Calendar selection). Clicking on the calendar icon will 
display the screen, once a date is selected from the screen the Open Ticket Date field will 
be populated with the appropriate date. 

Returns exact matches for the characters entered. It will not be formatted for presentation purposes. The 
user may enter delineating characters, but these will be stripped out before searching the database to find an 
exact date match. 

10.2 Validation 

None identified at this time, 

10.3 Business Exceptions 

None identified at this time. 

10.4 System Exceptions 

None identified at this time. 

11. Unit Plate Number 

11.1 Behavior 

This search criteria area will be an alphanumeric field. 
Returns exact matches for the characters entered. 

11.2 Validation 

None identified at this time. 

1 1 .3 Business Exceptions 

None identified at this time. 
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1 1 .4 System Exceptions 

None identified at this time. 

12. Bill-To/Shop Name/Number Group 

This group of controls includes the Bill-To/Shop Name and the Bill-To/Shop Number 
radio buttons as well as a criteria text box. 

12.1 Behavior 

This search criteria area will be an alphanumeric field regarding the text field. The Bill- 
To/Shop Name radio button will be the default selection upon screen entry . 
When the Bill-To/Shop Name radio button is selected an implied wildcard will be added 
at the end of the entered search criteria. Example: If the Bill-To/Shop Name search 
criteria entered were "Smith", you would receive back every open ticket with "Smith" in 
the Bill-To/Shop name. You would also receive every character string that matched 
"Smith" for the first 5 characters, but was longer than five characters. Given this, you 
would also receive, "Smither", "Smithson", "Smithy", etc. These longer character 
matches would be alphabetically ascending after the exact character matches of equal 
length. 

When the Bill-To/Shop Number radio button is selected it returns exact matches for the 
characters entered. 

An entry into this field will search the Bill-To and Shop roles that an account (customer) 
may be and return all matches. Currently, the roles to which the search may be applied 
are "Shop" and "Bill-To". 

12.2 Validation 

None identified at this time. 

12.3 Business Exceptions 

None identified at this time. 

12.4 System Exceptions 

Only one radio button can be selected at a given time. 

1 3. Search Results Area 

13.1 Behavior 

The result list will have a static column display sequence . All columns need to have the capability^ to be 
sorted, ascending and descending . The user selects an Open Ticket by clicking on the hyperlink associated 
with the desired data row. 

The user must have the appropriate security to view/edit the open ticket selected. 

13.2 Validation 

None identified at this time. 

13.3 Business Exceptions 

None identified at this time. 

13.4 System Exceptions 

None identified at this time. 
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14. Advanced Search / Simple Search hyperlink 

14.1 Behavior 

By clicking on the Advanced Search hyperlink, the user is presented with the advanced 
search functionality (Figure 3 - Advanced Search). Alternatively, by clicking on the 
Simple Search hyperlink, the user is presented with the default search screen (Figure 1 - 
Initial Entry - Simple Search). Any search criteria entered when on the default search 
screen will be passed to the Advanced Search screen if/when accessed . If the user 
navigates to the Simple Search screen from the Advanced Search screen, any search 
criteria entered into the advanced criterion that is not found on simple search will be lost. 

14.2 Validation 

None identified at this time, 

14.3 Business Exceptions 

None identified at this time. 

14.4 System Exceptions 

None identified at this time. 

1 5. Results Feedback Line Area 

15.1 Behavior 

This feedback area provides the user with the search result list count as well as list 
navigation. The user may select the block of records available as returned by the invoked 
search criteria. These blocks are identified by sequential numbers, along with a First (1 st 
block of records) and Last (last block of records). Also appearing will the Prev and Next. 
When negotiating through the result list the sequential numbers will change depending 
upon the block of records being viewed, other blocks of records can be accessed via the 
Prev and Next hyperlinks. For example looking at the Figure 2 - Simple Search with 
Search Results if the user selected Next, the sequential numbers listed will range from 2- 
6. If the user wishes to return to record block 1, they can either select First or Prev to 
view record blocks 1-5 again. 

15.2 Validation 

None identified at this time. 

15.3 Business Exceptions 

None identified at this time. 

15.4 System Exceptions 

None identified at this time. 

1 6. Button Line Area 
16.1 Behavior 

The Search image/button will invoke the search process, submitting the form to the 
server. The search can be invoked by clicking on the button or the user using the enter 
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The Reset control will return the screen to its default state. The default state being 


search criteria controls blank, group/branch default to terminal locale and an empty result 
area. 

The system should determine that no more than the set limit of three search criteria have 
been entered. 

16.2 Validation 

None identified at this time. 

16.3 Business Exceptions 

A limit of three search criteria may be entered. 

IfTicket Number is entered, all other search criteria are ignored . 

16.4 System Exceptions 

If more than three search criteria are entered the user should be presented with a feedback 
message stating "A limit of three search criteria may be entered, Please refine your 
search." 

17. Rules 

The Renter Name Last / First and Account Name search criteria have an implied wild card character placed 
directly after the entered text, all other search criteria fields on this screen are to be treated as exact matches 
with searching. 

The user may invoke the search without changing or adding any search criteria to the default screen entry 
criteria. The user may increase the scope of the search by selecting all groups and/or all branches, no 
detailed search criteria is necessary when using this screen. 

There is a limit of three search criteria on which a search may be executed. This does not include the Group 
and Branch selections. If more than three are entered the system will present to the user an appropriate 
feedback message stating that a maximum of three search criteria may be entered. This message will be 
displayed a form submittal. 

When there are not any matches to the input search criteria the user should be presented with a feedback 
message stating no items were found. This text should appear in the 0 listed below. 

1) If the search returns more open tickets than can be displayed on the screen at one time, then the 
system needs to present to the user the range of records they are viewing out of the total number of 
records 

All of the following search criteria, EXCEPT Ticket Number, will be limited to, or constrained by, the 
Group and Branch indicated or selected. 

18. Security 

The user must have the appropriate security level to access this screen. 
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Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the Open Ticket without 
Payment Use Case. This document also extends the screen action specification documents associated with 
the reservation iteration, which includes the following screens: 

• Driver 

• Additional Driver 

• Other Address 

• Insurance Detail 

• Cash Qualification 

• Referral 

• Bill-To 

• Vehicle / Shop 

• Dates / Rates 

• Notes 

• Application Locking 

The user enters the new ticket process via the menu Tickets :New. This process behaves in the same 
manner as the previously defined Reservation process, opening a new record as an open ticket rather than a 
reservation. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 
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2. Screen Prints 


|jE3846G 0101 Enterpnse^TcARS Application - Microsoft Internet Explorer provided by En MI1.!J 

% drivers l,w Z ' BBHill 111" 



Driver 


Other Address 


Insurance Detail 


Driver Name and Address - 


Last Name:* 


First Name: * 


r Phone Numbers- 
iHome: 


! Work: 


Extension: 


Employer: 


I Other Phone and Type: 


rHome Address- 
Address: * 



Drivers License- — 
License Number: Expiration 
* Date: 


l* 


ZIP: 


Country: 


UNITED STATI 


City: 


State: 


State 

Issuing Country: Issued: * 


[united statJ 

SSN: * 


Date of Birth: 


[ 

Eye Color: * Height: * 

I — i rn 

Hair Color: * Weight: * 


Primary Payment Method: 


Figure 1 - Driver 
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/|jE3846G 0101 Enterprise* ECARS Application - Microsoft Internet Explorer provided bj> Enterprise Rent-a-Car 



DATES /RATES 


r Driver Name and Address 


1 Cto 


VEHICtE/SHOP; 



Notes Taken : 1 


Last Name:* 


First Name: 


r 


-Phone Numbers- 
Home: 


i 


Work: 


Extension: 


! Employer: 


Other Phone and Type: 

fcz— m 


Credit Card Number 



-Home Address 

(I Same as Renter 
Address: 


ZIP: 


Country: 




City: 

State: 



•Drivers License 

Expiration 
License Number: Date: 


issuing Country: gjj*^. 


[UNITED STATj 
SSW: 


Eye Color: Height: 

n nn 

Hair Color: Weight: 


L 


Credit Card First Name 

H — ~~ 

CC Expiration Date 

r~~ — 71 


Credit Card Last Name 



Date of Birth: 


Figure 2 - Additional Driver 


*H Complete - Web Page Dialog 


© Complete 

O Complete - Unit Pend 

O Complete - Pre-Write 




Figure 3 - Complete 


3. Driver 

3.1 Driver 

3.1.1 Behavior 

This screen primarily behaves in the same manner as in Reservation. The following fields are required for 
this process: 

■ Last Name 
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■ First Name 
" Address 

■ §i 

■ Country 
■ 

■ State 

" License Number 

■ Expiration Date 

■ State Issued 

■ Date of Birth 

• Social Security Numbe r 
- Height 

■ Eye Color 

■ Weight 

■ Hair Color 

All conditionally required fields and behaviors defined during the Reservation iteration apply 

3.1.2 Validation 

No validation is necessary. 

3. 1.3 Business Exceptions 

None have been identified at this time. 

3.1.4 System Exceptions 

None have been identified at this time. 

4. Additional Driver 

4.1 Additional Driver 

4.1.1 Behavior 

This screen primarily behaves in the same manner as in Reservation. The following fields are required for 
this process: 

• Last Name 

• First Name 

• Date of Birth 

The following fields are conditionally required for this process: 

• If License Number is entered then 

■ State Issued 

■ Expiration Date (Drivers License section) 

• If Address is entered then 

■ Last Name 

■ First Name 
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■ Country 

■ £j£/ 

■ State 

All conditionally required fields and behaviors defined during the Reservation iteration apply, 

4. 1.2 Validation 

No validation is necessary. 

4.1.3 Business Exceptions 

None have been identified at this time. 

4.1.4 System Exceptions 

None have been identified at this time. 

5. Complete 

The complete process primarily behaves in the same manner as that defined in the Reservation iteration 
with the exception of the items listed below. This includes confirmation dialogs and validations. 

5.1 Form 


Q 5.1.1 Behavior 


iij 


H' 


Only one selection can be made. The default selection will be "Complete". 
The OK button will invoke the validation and save process, 
j* * The Cancel button will dismiss the form, placing the user back to where they invoked the process. 

IIJ 5.12 Validation 

0 = Complete - When this option is selected all validations are invoked. This includes the required fields 

I defined in the Driver and Additional Driver sections above as well as those conditionally required fields 

* and validations defined in the Reservation iteration. During this iteration of the Open Ticket project a 

ticket will cannot be saved in this status due to the missing Unit Pend data described below. Thus during 
this iteration a ticket can be saved in Complete - Pre-Write or Complete - Unit-Pend status only. 

Complete - Unit-Pend - When this option is selected ail validations except those involving an assigned unit 
are invoked. This includes Unit Number and License Plate Number which currently do not exist in the 
screens being used, these will be added to the Dates/Rates screen in future iterations of the Open Ticket 
project 

Complete - Pre-Write - When this option is selected the Drivers Last and First names along with the 
Billing Cycle from the Dates/Rates screen and only those validations that are conditional required 
information are invoked. These sets of validations are primarily defined in the Reservation use cases. 

If the user selects to save a ticket and it fails the necessary validation, the system will provide a feedback 
message listing the offending items. The user will then be allowed to save the ticket in a "lesser" open 
ticket status via the "Complete" button. 

5.1.3 Business Exceptions 
None have been identified at this time. 

5.1.4 System Exceptions 
None have been identified at this time. 
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6. Rules 


6.1 Required Fields 

Since this document is an extension of the screen action specification document defined in the Reservation 
and Open Ticket projects, the required fields and conditionally required fields along with all of the 
associated validations pertain to this document as well. 

6.2 Saving 

The save is completed when the user saves the ticket. When the ticket saves successfully the application 
will navigate to the Ticket Search screen, 

7. Security 

The user must have the appropriate security level to access the screens. 


sip h 
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Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the Open Ticket Retrieve Rate(s) 
screens. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 


2. Open Ticket Retrieve Rates - Screens 


cgj Rates New - Microsoft Internet Explore; provided by Enterprise Rent-a-Car 


mmm 



Top portion of Rates panel 
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£j Rates Mew - Microsoft Internet Explorer provided by Enterprise Rent-a-Car |§S«lIsS' 
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Bottom portion of Rates Panel 
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-'H Rates New - Microsoft Internet Explorer provided by Enterprise Rent-a-Cai 



Start Charges if Different pop-up box 
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*H| Bates Hew - Microsoft Internet Explorer provided by Enterprise Rent-a-Cai 
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Change Return Information pop-up box 


Confidential 


©Enterprise Rent-A-Car ? 
2000 


10 


Enterprise Rent-A-Car 


Reservation Dates and Rates Screen Spec - Microsoft Word 


: :s= a 
is? ; 


2 ! 



SSS K 


Account Search Display 
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<sl Rates New - Microsoft Internet Explorer proyided by Enterprise Rent-a-Car 



Units Available pop-up box 
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Driver summary 1 
Driver summary 2 

Referral sum 1 
Referral sum 2 


DATES/ RATES 


Dates summary 1 
Dates summary 2 


Bill -To summary 1 
Bill-To summary 2 [ 

HBfiflHH Ky^^H ] 

Vehicle/Shop 1 |i 
Vehicle/Shop 2 


Dates/Rates 


| -Select - 


- Options Its! 


Notes summary 1 
Notes summary 2 



Res • 411781 


[Tkt ^234567|cb!r^6i2^ 


Get Rates display area 
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H Rates New - Microsoft Internet Explorer pwyided by Enter prise Rent -a-Cai 


Bill-To summary 1 
Bill-To summary 2 


VEHTCtE/SHOP 


Vehicle/Shop 1 
Vehicle/Shop 2 

Notes summary 1 
Notes summary 2 


-Coverages .J CPW,PAI,SLP- 
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SLP 8 [11299 , [Weekly |1 2/22/2002 ; [3 55PM ! (12/25/2002 ^ pOPM 

i-seied-ji i i [ i r 1 I r 




I::-.:;.:;,,.::;:.:;.:- . 


i Res -< 41178i : 


Tkt- 23456? 


Cbk - 363227] 



Expanded Coverages display area 


3. Open Ticket Number 

3.1 Behavior 

This area shows the unique open ticket number that has been assigned to the newly created 
ticket. The ticket number is 6 alphanumeric characters long. 
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If another reservation or ticket is open, its reservation/ticket number will be displayed in this area 
as well. The user will have the ability to have up to 3 reservations/tickets open at a time. A 
hyperlink will be available on the reservation/ticket numbers of the reservations that are NOT 
currently being displayed. For the reservation/ticket that is currently displayed, the 
reservation/ticket number will not have a hyperlink available. This is to allow the user to navigate 
between the open reservations/ticket. 

3.2 Validation 

None identified at this time. 

3.3 Business Exceptions 

If the user tries to open a 4 th reservation, the system will display a message 
stating, "A maximum of 3 reservations/tickets may be displayed". 

3.4 System Exceptions 

None identified at this time. 


4. Pick Up Group and Branch Area 

4.1 Behavior 

This area will be defaulted to the terminal location group and branch. A group and branch are required and 
it will be displayed in the header information. 

4.2 Validation 

None, it will correspond to the PeopleSoft determined values. 

4.3 Business Exceptions 

None identified at this time. 

4.4 System Exceptions 

None identified at this time. 

5- Pick Up Date Area 

5.1 Behavior 

This area will be an alphanumeric field. It will not be formatted for presentation purposes. 

The user may enter delineating characters, but these will be stripped out before writing to 

the database. There should be a calendar function available which would allow the user to 

select a date from a calendar icon, or similar feature, instead of entering a value. If the 

user selects a date from the calendar icons, it will be displayed in the date area formatted 

appropriately by the locale. (As determined for all locale specific formatting.) 

It should initially default to the current date. 

5.2 Validation 

It will be a valid month, day and year combination. 
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5.3 Business Exceptions 

If the user enters or selects a Pick-up date which is prior to the current date, display a message 
"Pick-up date is prior to current date. Is this correct?" 

If the user enters or selects a Pick-up date which is in the future, display a message "Pick-up date 
cannot be in the future." 

A pick up date is required. If it is blanked out, not input or selected, display a message "Must 
specify a pick-up date". 

5.4 System Exceptions 

If not a valid month, day and year combination, the normal date in error message should 
be displayed. 

6. Pick Up Time Area 

6.1 Behavior 

In locales where time is shown by AM PM designation: 

This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute and 
AM/PM designation, and a maximum of Hour Hour Minute Minute AM/PM designation.i.e. 945A, 
would designate 9:45 in the morning. A leading zero may precede the hour, but is not required 
and will be removed before saving to the database. The minutes must be two numeric values. 
The AM/PM designation of "A" or "P" must also be indicated. The user may enter delineating 
characters, but these will be removed before saving to the database. 

In locales where time is shown by 24 hour designation: 

This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute, and 
a maximum of Hour Hour Minute Minute, i.e. 945 would designate 9:45 in the morning, 1425 
would designate 2:25 in the afternoon. A leading zero may precede the hour, but is not required 
and will be removed before saving to the database. The minutes must be two numeric values. 
The user may enter delineating characters, but these will be removed before saving to the 
database. 

It should initially default to the current time. 

6.2 Validation 

In locales where time is shown by AM PM designation: 

Time increments can range from 1 200A to 1 1 59A and from 1 200P until 1 1 59P . If an entry is not 
within these two ranges display "Must specify a valid time". 

In locales where time is shown by 24 hour designation: 

Time increments can range from 0000 to 2400. If an entry is not within this range display "Must 
specify a valid time". 

6.3 Business Exceptions 

A pick-up time cannot be selected if there is not a pick-date selected. If this is attempted, 
display a message "Must specify a pick-up date 9 '. 
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If the user enters or selects a Pick-up time which is prior to the current time, display a message 
"Pick-up time is prior to current time. Is this correct?" 

A pick up time is required. If the default value is removed, display a message 
"Must specify a pick-up time". 

It is possible to have a pick-up time in the future, but the pick-up date must be the same. 


6.4 System Exceptions 

None identified at this time. 

7. Pick Up Time Drop Down 

7.1 Behavior 

This drop down icon will display the time in 15-minute increments. When 
selected, it should be positioned to the % hour increment immediately preceding 
the current time and format according to the locale's format. 

7.2 Validation 

None identified at this time. 

7.3 Business Exceptions 

A pick-up time cannot be selected if there is not a pick-date selected. If this is attempted, 
display a message "Must specify a pick-up date". 

A pick up time is required. If the default value is removed, display a message 
"Must specify a pick-up time". 

If the user enters or selects a Pick-up time which is prior to the current time, 
display a message "Pick-up time is prior to current time. Is this correct?" 

It is possible to have a pick-up time in the future, but the pick-up date must be the same. 

7.4 System Exceptions 

None identified at this time. 
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8. Start Charges if Different Button Function 

8.1 Behavior 

Selecting this function will present the user will a pop-up box showing date and time 
fields. Information entered in the pop-up box will be displayed under the Start Charges if 
Different button function. 

8.2 Validation 

See specific areas. 

The ok feature will save date and time if valid. 

The cancel feature will close the pop-up and not save entered information, if any. 

8.3 Business Exceptions 

See specific areas. 

8.4 System Exceptions 

None identified at this time. 

9. Start Charges if Different Date Area 

9.1 Behavior 

This area will be an alphanumeric field. It will not be formatted for presentation purposes. 

The user may enter delineating characters, but these will be stripped out before writing to 

the database. There should be a calendar function available which would allow the user to 

select a date from a calendar icon, or similar feature, instead of entering a value. If the 

user selects a date from the calendar icons, it will be displayed in the date area formatted 

appropriately by the locale. (As determined for all locale specific formatting.) 

It should initially default a blank. 

9.2 Validation 

It will be a valid month, day and year combination. 

9.3 Business Exceptions 

The start charges if different date must be greater than or equal to the pick-up date, and less than 
or equal to the return date. 

If the user enters or selects a start charges if different date which is prior to the Pick-up date, 
display a message "Start charges dates cannot be prior to pick-up date." 

if the user enters or selects a start charges if different date which is after the return date, display 
a message "Start charges dates cannot be after return date." 

9.4 System Exceptions 

If not a valid month, day and year combination, the normal date in error message should 
be displayed. 
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10. Start Charges if Different Time Area 

10.1 Behavior 

In locales where time is shown by AM PM designation: 

This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute and 
AM/PM designation, and a maximum of Hour Hour Minute Minute AM/PM designation.i.e. 945A, 
would designate 9:45 in the morning. A leading zero may precede the hour, but is not required 
and will be removed before saving to the database. The minutes must be two numeric values. 
The AM/PM designation of "A" or "P" must also be indicated. The user may enter delineating 
characters, but these will be removed before saving to the database. 

In locales where time is shown by 24 hour designation: 

This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute, and 
a maximum of Hour Hour Minute Minute, i.e. 945 would designate 9:45 in the morning, 1425 
would designate 2:25 in the afternoon. A leading zero may precede the hour, but is not required 
and will be removed before saving to the database. The minutes must be two numeric values. 
The user may enter delineating characters, but these will be removed before saving to the 
database. 

It should initially default to blank. 
Validation 

In locales where time is shown by AM PM designation: 

Time increments can range from 1200A to 1 159A and from 1200P until 1 159P. If an entry is not 
within these two ranges display "Must specify a valid time". 

In locales where time is shown by 24 hour designation: 

Time increments can range from 0000 to 2400. If an entry is not within this range display "Must 
specify a valid time". 

1 0.3 Business Exceptions 

A start charges if different time cannot be selected if there is not a start charges if 
different date. If this is attempted, display a message "Must specify a start charges if 
different date". 

The start charges if different time must be greater than or equal to the pick-up time, if the start 
charges if different date is equal the pick-up date. 

The start charges if different time must be less than or equal to the return time, if the start 
charges if different date is equal the return date. 

If the start charges if different date is equal to the pick-up date and the user enters or selects a 
start charges if different time which is prior to the Pick-up time, display a message "Start charges 
time cannot be prior to pick-up time" 

If the start charges if different date is equal to the return date and the user enters or selects a 
start charges if different time which is after the return time, display a message "Start charges time 
cannot be after return time" 


ft 
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10.4 System Exceptions 

None identified at this time. 

1 1 . Start Charges if Different Time Drop Down 

11.1 Behavior 

This drop down icon will display the time in 15-minute increments. When 
selected, it should be positioned to the % hour increment immediately preceding 
the current time and format according to the locale's format. 

11.2 Validation 

None identified at this time. 

11.3 Business Exceptions 

A start charges if different time cannot be selected if there is not a start charges if 
different date. If this is attempted, display a message "Must specify a start charges if 
different date". 

The start charges if different time must be greater than or equal to the pick-up time, if the start 
charges if different date is equal the pick-up date. 

The start charges if different time must be less than or equal to the return time, if the start 
charges if different date is equal the return date. 

If the start charges if different date is equal to the pick-up date and the user enters or selects a 
start charges if different time which is prior to the Pick-up time, display a message "Start charges 
time cannot be prior to pick-up time" 

If the start charges if different date is equal to the return date and the user enters or selects a 
start charges if different time which is after the return time, display a message "Start charges time 
cannot be after return time" 

1 1 A System Exceptions 

None identified at this time. 


12. Return Date Area 

12.1 Behavior 

This area will be an alphanumeric field. It will not be formatted for presentation purposes. 

The user may enter delineating characters, but these will be stripped out before writing to 
the database. There should be a calendar function available which would allow the user to 
select a date from a calendar icon, or similar feature, instead of entering a value. If the 
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user selects a date from the calendar icons, it will be displayed in the date area formatted 
appropriately by the locale. (As determined for all locale specific formatting.) 
It should default to a blank area. 

12.2 Validation 

It will be a valid month, day and year combination. 

12.3 Business Exceptions 

A return date is required. 

If the user does not enter a date a message is displayed "Return date must be specified". 

The return date cannot be before the pick-up date. If it is, display message "Return date must be 
equal to, or after Pick-up date". 

12.4 System Exceptions 

If not a valid month, day and year combination, the normal date in error message should 
be displayed 

1 3. Return Time Area 

13.1 Behavior 

In locales where time is shown by AM PM designation: 

This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute and 
AM/PM designation, and a maximum of Hour Hour Minute Minute AM/PM designation.i.e. 945A, 
would designate 9:45 in the morning. A leading zero may precede the hour, but is not required 
and will be removed before saving to the database. The minutes must be two numeric values. 
The AM/PM designation of "A" or "P" must also be indicated. The user may enter delineating 
characters, but these will be removed before saving to the database. 

In locales where time is shown by 24 hour designation: 

This is an alphanumeric area. A valid entry to this area is a minimum of Hour Minute Minute, and 
a maximum of Hour Hour Minute Minute, i.e. 945 would designate 9:45 in the morning, 1425 
would designate 2:25 in the afternoon. A leading zero may precede the hour, but is not required 
and will be removed before saving to the database. The minutes must be two numeric values. 
The user may enter delineating characters, but these will be removed before saving to the 
database. 

This should default to a blank area. 

13.2 Validation 

In locales where time is shown by AM PM designation: 

Time increments can range from 1 200A to 1 1 59A and from 1 200P until 1 1 59P. If an entry is not 
within these two ranges display "Must specify a valid time". 

In locales where time is shown by 24 hour designation: 

Time increments can range from 0000 to 2400. If an entry is not within this range display "Must 
specify a valid time". 
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1 3.3 Business Exceptions 

A return time is required. 

If the user does not enter a time a message is displayed "Return time must be specified". 

A return time cannot be selected if there is not a return date entered or selected. If this is 
attempted, display a message "Must specify a return date". 

If the return date is the same as the pickup date, then the return time must be later than 
the pickup time. If not, display a message "When pickup and return date are the same, 
return time must be later than pickup time". 


13.4 System Exceptions 

!:* None identified at this time. 


14. Return Time Drop Down 


14.1 Behavior 

This drop down icon will display the time in 15-minute increments. When 
selected, it should be positioned to the % hour increment immediately preceding 

]\ the current time and format according to the locale's format. 

i y 

Hi 14.2 Validation 

r j None identified at this time. 

1 4.3 Business Exceptions 

A return time is required. 

If the user does not enter a time a message is displayed "Return time must be specified". 

A return time cannot be selected if there is not a return date entered or selected. If this is 
attempted, display a message "Must specify a return date". 

If the return date is the same as the pickup date, then the return time must be later than 
the pickup time. If not, display a message "When pickup and return date are the same, 
return time must be later than pickup time". 

14.4 System Exceptions 

None identified at this time. 
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15. Change Return Location Button Function 

15.1 Behavior 

Selecting this function will present the user will a pop-up box that will show the default 
group, branch (to the terminal's location) and return method drop down listings and a 
return location text area. 

Only areas with changed information will be displayed under the Change Return 
Information button function. The terminal location default group and branch will NOT be 
displayed unless changes are made. 

15.2 Validation 

See specific areas. 

There are not any required areas. 

The ok feature will save selected or entered information. 

The cancel feature will close the pop-up and not save entered information, if any. 

15.3 Business Exceptions 

See specific areas. 

15.4 System Exceptions 

None identified at this time. 

16. Change Return Location Group 

16.1 Behavior 

This drop down listing will be limited to those groups that exist at any point in time. The 
selection of "AH" is NOT included in the list. The users would also like to have the 
ability to type a character, alpha or numeric, into the criteria area and have the drop down 
list position to the character. (If the user enters an "H" the drop down list would position 
to the first string beginning with "H" in the list) 
This should default to the terminal location group. 

16.2 Validation 

The items appearing in the list are static; the user cannot add items to the list 
dynamically. 

1 6.3 Business Exceptions 

None identified at this time. 

16.4 System Exceptions 

None identified at this time. 

17. Change Return Location Branch 

17.1 Behavior 

This drop down listing will be limited to those branches that exist within the group at any point in time. The 
selection of "All" is NOT included in this selection list. The users would also like to have the ability to 
type a character, alpha or numeric, into the criteria area and have the drop down list position to the 
character. (If the user enters an "H" the drop down list would position to the first string beginning with 
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"H" in the list) 

Branch items appearing in the list will be limited to the Group item selected. Once the selected Group item 
has changed, the branch will be set to blanks. This will require the user to select a branch, at which time the 
display area will be refreshed, repopulated and repositioned. 
This will default to the terminal location branch. 

17.2 Validation 

The items appearing in the list are static; the user cannot add items to the list 
dynamically. This list will be limited to the branches associated with the group selected. 

17.3 Business Exceptions 

None identified at this time. 

17.4 System Exceptions 

None identified at this time. 

18. Change Return Location Method 

18.1 Behavior 

This drop down listing will be limited to values associated with the return method, 
currently the valid values are: Branch, Drop and Ride Back in North America and 
Branch, Ride Back and Automatic Pickup (APU) in Europe. 

18.2 Validation 

The items appearing in the list are static; the user cannot add items to the list 
dynamically. 

1 8.3 Business Exceptions 

None identified at this time. 

18.4 System Exceptions 

None identified at this time. 

1 9. Change Return Location Text Area 

19.1 Behavior 

This will be a free form text area. 

19.2 Validation 

None identified at this time. 

19.3 Business Exceptions 

None identified at this time. 
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19.4 System Exceptions 

None identified at this time. 

20. Account Name Drop Down 

20.1 Behavior 

This area will be a drop down list of the Branch's short list, for North America. For 
everywhere else it will be the Group's Account list. If there are any of the 
following associated with the particular open ticket, they will appear at the top or 
beginning of the list in the following order. 

1) Any Bill-To Accounts 

2) Any Referral Accounts 

3) Any Shop Accounts 

The information displayed about an Account will be in the following order: 

1) Account Name 

2) Account Number 

3) Rental Type 

4) Owning Group/Branch 

5) Address 

6) City 

7) State 

8) Zip 

9) Telephone 

The Account Name in the display area will have a hyper-link which, when 
selected, will populate the Account Name, Account Number, Account Type and 
Rate Plan areas on the Dates and Rates panel. 

20.2 Validation 

None identified at this time. 

20.3 Business Exceptions 

If Account name or number is selected and the following account types are determined, 
then other areas will be defaulted to the values shown. 


20.4 System Exceptions 

None identified at this time. 
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21 - Account Number Area 

21.1 Behavior 

This area will allow entry of alphanumeric values. When there is a match, the system will populate 
the Account Name, Account Number, Account Type and Rate Plan areas on the Dates and Rates 
panel. The search will be executed as the user tabs off of the field. 


21.2 Validation 

None identified at this time. 

21 .3 Business Exceptions 

If there is not an exact match, then display a message "Account number does not exist." 

21.4 System Exceptions 

None identified at this time. 


22. Account Search Button 

22.1 Behavior 

Selecting this button will display the account search panel. See Referral Source Supplementary 
Specification for details. 

22.2 Validation 

None identified at this time. 

22.3 Business Exceptions 

None identified at this time. 

22.4 System Exceptions 
None identified at this time. 

23, Rate Plan Drop Down 
23.1 Behavior 

This area will be populated when an Account Name or Account Number has been selected. 
If there are multiple plans associated with an Account, it will list all of the rateplans associated 
with that Account, and the user must choose one. When there are multiple rate plans, the value 
"select" will appear in area so the user knows that there are multiple rate plans and selection of a 
single one is required. 

If there is only a single rate plan associated with and Account then the rate plan pop-up box will 
appear show all of the car classes and rates associated with that account. 


23.2 Validation 

None identified at this time. 
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23.3 Business Exceptions 

If no rate plans are associated with an Account then a message is displayed "No rates were found". 

23.4 System Exceptions 

None identified at this time. 

24. Rental Type Drop Down 

24.1 Behavior 

This area will be a drop down list of Rental types. 

Rental Type 

Insurance 

Bodyshop 

Dealership 

Retail 

Corporate 

Other 

Employee 

Government 

Fleet 

Truck 

Rideshare 

Walk-in 


24.2 Validation 

Any value selected is valid. 

24.3 Business Exceptions 

None identified at this time. 

24.4 System Exceptions 

None identified at this time. 

25, Billing Cycle Drop Down 

25.1 Behavior 

This area will initially default to the billing cycle associated with the Account and Rate Plan 

selected. It may be changed to anther value. 

Drop down domain values are Blank, 24 Hour and Calendar Day. 

25.2 Validation 

None identified at this time. 
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25.3 Business Exceptions 

See list in account name area for defaults, based on account. 


25.4 System Exceptions 

None identified at this time 

26. Car Class to Charge for Drop Down 

26.1 Behavior 

This area will be a drop down list that also allows entry of alphanumeric values. The drop down 
list will be comprised of the most commonly used car classes. The entry of alphanumeric values 
will be edited against a larger more comprehensive car class list. If there is a successful 
vehicle/unit search, this will be populated with that particular vehicle's car class. It is possible to 
change this value. 

Drop down list values 

Class and Type 

ECAR 

CCAR 

I CAR 

SCAR 

FCAR 

PCAR 

LCAR 

MVAR 

XFAR 

XPAR 

XXAR 

XVAR 

26.2 Validation 

None identified at this time. 

26.3 Business Exceptions 

If the values entered are not one of the ones listed below, a message is displayed "Must enter a valid car 
class". 

Car Class Edit List of Values 

Class and Type 

MCAR 
MBAR 
MDAR 
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MXAR 


MSAR 


MTAR 


MWAR 


MVAR 


MFAR 


MPAR 


ECAR 


EBAR 


EDAR 


EXAR 


ESAR 

5 . 

ETAR 

H 

EWAR 

.3 

EVAR 

sx: 
- I 5 

EFAR 

Ml 

EPAR 

O 

CCAR 


CBAR 

yi 

s: 

CDAR 

S : 

a 

CXAR 

Ml 

CSAR 


CTAR 

0! 

CWAR 

X^ V W # »l X 

'fi P 

CVAR 

V # \l X 


CFAR 


CPAR 


ICAR 


IBAR 

1 UV\I x 


IDAR 


IXAR 


ISAR 


ITAR 

1 I f\l X 


IWAR 

1 V V x. 


IVAR 


IFAR 


IPAR 


SCAR 


SBAR 


SDAR 


SXAR 


SSAR 


STAR 
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SWAR 

SVAR 

SFAR 

SPAR 

FCAR 

FBAR 

FDAR 

FXAR 

FSAR 
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XPAR 


26.4 System Exceptions 

None identified at this time. 


27. Unit/Vehicle Input Search Area 
27.1 Behavior 

This will be an alphanumeric input area, consisting of 3 areas. The Unit Number, the License 
Number and the last 6 Digits of the Vehicle Identification Number, (VIN). 


The Unit Number must be entered, with at least one of the other two. Using this information, the 
system will be able to determine the associated car class, for the rate source selected. 
If there is only a single rate plan associated with the car class and rate source then the system 
will return rates for that particular unit/vehicle and the rates associated with all applicable 
coverages, PAI, CDW and SLP. 


If there is more than one rate plan associated with the rate source, then the system will display all 
rate plans determined by the car class and allow the user to select a single rate plan. After a 
single rate plan is selected, then the system will return rates for that particular unit/vehicle and the 
rates associated with all applicable coverages, PAI, CDW and SLP. 

At a minimum, we will need to return the associated Unit Number, Year, Make, Model and Car 
Class of the different vehicles. This information will need to be saved with the transaction also. 
It will also be displayed within the unit information box when retrieved. The search will initiate when the 
user tabs off of the last field. 


27.2 Validation 

None identified at this time. 

27.3 Business Exceptions 

If the unit/vehicle selected belong to a car class, which is not associated with a rate plan for the designated 
rate source, then a message is displayed "Rate plan does not contain selected car class". 
If the user has not entered one of the required fields, display a message "Unit number and license plate 
number or last 6 of VIN required. 


27.4 System Exceptions 

None identified at this time. 

At a minimum, we will need to return the associated Unit Number, Year, Make, Model and Car 
Class of the different vehicles. This information will need to be saved with the transaction also. 
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28. Units Available Search Button Function 

28.1 Behavior 

Selecting this button will display the Units available search pop-up panel. 

The pop-up box will display: 
Group and branch drop down boxes. 

Unit number, License plate number and Last 6 of VIN input areas. 

A search function which will execute the search 

A display of the vehicles available table with columns: 

Year, Make, Model, Series, Car Class, License Plate Number and Location. 

The Group and Branch drop down boxes will default to the terminal location. 

The Unit Number, License Plate Number and Last 6 of VIN, will default to blank. Any one, two or all three 
may be used to search the Vehicle Data base. 

The vehicles available display will default display the available units at the terminal location default group 
and branch. 

28.2 Validation 

None identified at this time. 

28.3 Business Exceptions 

There must be at least one search criteria to execute a search, otherwise display a message "Must specify at 
least one search criteria". 

28.4 System Exceptions 

None identified at this time. 

29. Get Rates Button 

29.1 Behavior 

Selection of this button will have the system execute a search for rate plans associated with the information 
entered. 

29.2 Validation 

None identified at this time. 

29.3 Business Exceptions 

At a minimum there must be an Account Name or an Account Number to search for rates. If the user 
selects this button without one of these a message is displayed "Must specify account name or number". 

29.4 System Exceptions 

None identified at this time. 
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30. Rate Plan - Pop-Up Display Area 

30.1 Behavior 

This is a pop-up window that will display the rates of a rate plan associated with 
an Account. Information displayed is: 

Rate pop-up box columns and information: 

• Car Class 

• Daily - Rate and Mileage 

• Weekly - Rate and Mileage 

• Monthly - Rate and Mileage 

• Hourly - Rate 

• Mileage Charge 

Car class will have a hyper-link which will allow the user to select the rate they want. This will then 
populate the rates display area on the Dates and Rates panel. 

30.2 Validation 

None identified at this time. 

30.3 Business Exceptions 

If an Account has more than one rate plan associated with it, then this 
information cannot be displayed until the Rate Plan area has a value. 

If an Account has a single rate plan associated with it, then this information is 
displayed after the Account Name is selected or an Account Number is entered. 

If an Account has a single rate plan and there is a value in the Car Class area, 
and that car class is in the rate plan, then the rates display area of the Dates and 
Rates panel is populated with the appropriate information and the rate plan pop- 
up window is NOT displayed. 

If an Account has multiple rate plans and there is a value in the Car Class area, 
and there is not a value in Rate Plan area, a message should display "Must 
specify a rate plan". 

If an Account has a multiple rate plans, and there is a value in the Rate Plan area 
and there is a value in the Car Class area, and that car class is in the rate plan, 
then the rates display area of the Dates and Rates panel is populated with the 
appropriate information and the rate plan pop-up window is NOT displayed. 

If an Account has a single rate plans, and there is a value in the Car Class area, 
but that car class is not in the rate plan, then a message is displayed, "Rate plan 
does not contain selected car class". 
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If an Account has a multiple rate plans, and there is a value in the Rate Plan area 
and there is a value in the Car Class area, but that car class is not in the rate 
plan, then a message is displayed "No rates found for car class selected". 

30.4 System Exceptions 

None identified at this time 

31 . Rate Plan - Display Area 

31.1 Behavior 

This is a display area that will be populated with the rates associated with a 
particular car class of a rate plan associated with an Account. 
Information displayed is: 

• Car Class 

• Daily Rate 

• Daily Mileage 

• Weekly Rate 

• Weekly Mileage 

• Monthly Rate 

• Monthly Mileage 

• Hourly Rate 

• Mileage Charge 

• No Charge Check Box 

All of the information presented, except Car Class, has the ability to be edited or 
changed. 

There is an interaction between the Mileage Charge and the No Charge Check Box. If the 
No Charge Check Box is selected, then the Mileage Charge is set to zero and the area 
disabled. Unselecting the No Charge Check Box will enable the Mile Charge area for 
entering values. 

31.2 Validation 

None identified at this time. 

31.3 Business Exceptions 

Negative values may not be entered. If attempted, display message "Must specify positive 
amount". 

31.4 System Exceptions 

None identified at this time 
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32. Coverages Area 

32.1 Behavior 

This will be a collapsible/expandable area to display the different coverages. There will be some 
sort of button functionality which will allow this area to be expanded or collapsed. In either state 
the selected coverages will be listed to the side of the button function. Values within area may be 
changed or edited. 

Each area will have a drop-down box to be able to select additional items. 

It is anticipated that the information to be displayed for each instance of the coverage is: 
Description 
Rate 

Rate Frequency 
Start Date 
Start Time 
End Date 
End Time 

All of this information will come from what is maintained in the Perot systems. 

32.2 Validation 

None identified at this time. 

32.3 Business Exceptions 

Negative values may not be entered in the rate area. If attempted, display message "Must 
specify positive amount". 

Dates may be changed, but cannot be beyond the Pick-up and/or Return date range. If 
this is attempted, display appropriate message, either "Start date cannot be before pick-up 
date" or "End date cannot be after return date". 

Similarly, Times may be changed, but cannot be beyond the Pick-up and/or Return time 
range. If this is attempted, display appropriate message, either "Start time cannot be 
before pick-up time" or "End time cannot be after return time". 


32.4 System Exceptions 

None identified at this time. 

33. Coverages - CDW Area 

33.1 Behavior 

This area will initially default to the amount of Collision Damage Waiver associated with the Car 
Class and Rate Plan for the particular Account. This area may be changed or edited. 
Each area will have a drop-down box to be able to select additional items. 

33.2 Validation 

None identified at this time. 
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33.3 Business Exceptions 

Negative values may not be entered in the rate area. If attempted, display message "Must 
specify positive amount". 

Dates may be changed, but cannot be beyond the Pick-up and/or Return date range. If 
this is attempted, display appropriate message, either "Start date cannot be before pick-up 
date" or "End date cannot be after return date". 

Similarly, Times may be changed, but cannot be beyond the Pick-up and/or Return time 
range. If this is attempted, display appropriate message, either "Start time cannot be 
before pick-up time" or "End time cannot be after return time". 

33.4 System Exceptions 

None identified at this time 

34. Coverages - PAI Area 

34.1 Behavior 

This area will initially default to the amount of Personal Accident Insurance associated with the 
Car Class and Rate Plan for the particular Account. This area may be changed or edited. 
Each area will have a drop-down box to be able to select additional items. 

34.2 Validation 

None identified at this time. 

34.3 Business Exceptions 

Negative values may not be entered in the rate area. If attempted, display message "Must 
specify positive amount". 

Dates may be changed, but cannot be beyond the Pick-up and/or Return date range. If 
this is attempted, display appropriate message, either "Start date cannot be before pick-up 
date" or "End date cannot be after return date". 

Similarly, Times may be changed, but cannot be beyond the Pick-up and/or Return time 
range. If this is attempted, display appropriate message, either "Start time cannot be 
before pick-up time" or "End time cannot be after return time". 

34.4 System Exceptions 

None identified at this time 


35. Coverages - SLP Area 

35.1 Behavior 

This area will initially default to the amount of Supplemental Liability Protection associated with 
the Car Class and Rate Plan for the particular Account. This area may be changed or edited. 
Each area will have a drop-down box to be able to select additional items. 

35.2 Validation 

None identified at this time. 
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35.3 Business Exceptions 

Negative values may not be entered in the rate area. If attempted, display message "Must 
specify positive amount". 

Dates may be changed, but cannot be beyond the Pick-up and/or Return date range. If 
this is attempted, display appropriate message, either "Start date cannot be before pick-up 
date" or "End date cannot be after return date". 

Similarly, Times may be changed, but cannot be beyond the Pick-up and/or Return time 
range. If this is attempted, display appropriate message, either "Start time cannot be 
before pick-up time" or "End time cannot be after return time". 


35.4 System Exceptions 

None identified at this time. 

36. Cancel Function Button 

36.1 Behavior 

The Cancel image/button will take the user to the last panel accessed. 

36.2 Validation 

None identified at this time. 

36.3 Business Exceptions 

None identified at this time. 

36.4 System Exceptions 

None identified at this time. 


General Requirements 

37. Error Message - Session Already Exists for this Browser instance 

This captures the Error Message generated when the user attempts to open a new session 
on the terminal without opening a new instance of the IE browser. 

37.1 Behavior 

When the user attempts to open a new session on the same terminal without opening a 
new instance of the browser, display the following error message: 

"There is a session already open for this browser on this terminal. 
Please use that session or open a new browser." 

For Informational purposes: This situation can occur when the user attempts to open the 
active session by selecting the window titled "About" and uses the "back" button to 
navigate to the previous page. 
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38. Security 

The user must have the appropriate security level to access these screens. The user is allowed to view or 
print anything. It is when they attempt to edit a reservation that their security restrictions will be enforced. 
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Screen Action Specification 


1. Introduction 

This document will describe the behavioral characteristics associated with the Vehicle / Shop screen. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 


2. Screen Prints 


^Vehicle / Shop - Microsoft Internet tHplorer prided by Enterprise Rent-a-Car 
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Figure 1 - Vehicle / Shop (North America) 
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J Vehicle Shop - Ireland and United Kingdom - Microsoft Internet Explorer provided by Enterprise Rent-a-Car 
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Figure 2 - Vehicle / Shop (Ireland & United Kingdom) 
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Figure 3 - Vehicle / Shop (Germany) 
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3. Vehicle / Shop (Figure 1, Figure 2, Figure 3) 

3.1 Registration Number (Vehicle area of Renter's Vehicle sub-screen) 

3.1.1 Behavior 

This is a text field in which the user may enter a Registration Number. This field only 
appears on the European versions (Figure 2, Figure 3) of the application and is hidden on 
the North American version (Figure 1). 

3.12 Validation 

No validation is necessary. 

3. 1.3 Business Exceptions 

None have been identified at this time. 

3. 1.4 System Exceptions 

None have been identified at this time. 

3.2 Year (Vehicle area of Renter's Vehicle sub-screen) 

3.2.1 Behavior 

This is a drop-down field containing the Years available for searching. This field is 
hidden on the Ireland and United Kingdom version (Figure 2) of the application and is 
visible on the North American and German versions (Figure 1, Figure 3). 

3.2.2 Validation 

No validation is necessary. 

3. 2. 3 Business Exceptions 

None have been identified at this time. 

3. 2. 4 System Exceptions 

None have been identified at this time. 

3.3 Class (Vehicle area of Renter's Vehicle sub-screen) 

3.3.1 Behavior 

This is a drop-down field containing a list of numbers from 1 to 10 for the User to select as the Class. 
This field only appears on the German version (Figure 3) of the application and is hidden on the North 
American and the Ireland and United Kingdom versions (Figure 1, Figure 2). 

3.3.2 Validation 

No validation is necessary. 

3. 3. 3 Business Exceptions 

None have been identified at this time. 

3. 3. 4 System Exceptions 

None have been identified at this time. 
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3.4 Make (Vehicle area of Renter's Vehicle sub-screen) 

3.4.1 Behavior 

This is a drop-down field containing a list of makes available for the Year (3.2) selected. 
If a Make different from "Other Make" is selected from the list, the Other Make (3.5) 
field should be cleared out. This field appears on all versions (Figure 1, Figure 2, Figure 
3) of the application. 

3.4.2 Validation 

No validation is necessary. 

3.4. 3 Business Exceptions 

None have been identified at this time. 

3.4.4 System Exceptions 

None have been identified at this time. 

3.5 Other Make (Vehicle area of Renter's Vehicle sub-screen) 

3.5.1 Behavior 

This is a text field in which the user may enter a Make that was not available in the drop- 
down. If a value is entered, the Make (3.4) drop-down field should be cleared out if it has 
a value different from "Other Make". This field appears on all versions (Figure 1, Figure 
2, Figure 3) of the application. 

3.5.2 Validation 

No validation is necessary. 

3. 5. 3 Business Exceptions 

None have been identified at this time. 

3. 5. 4 System Exceptions 

None have been identified at this time. 

3.6 Model (Vehicle area of Renter's Vehicle sub-screen) 

3.6.1 Behavior 

This is a drop-down field containing a list of models available for the Make (3.4) 
selected. If a Model different from "Other Model" is selected from the list, the Other 
Model (3.7) field should be cleared out. This field appears on all versions (Figure 1, 
Figure 2, Figure 3) of the application. 

3.6.2 Validation 

No validation is necessary. 

3. 6. 3 Business Exceptions 

None have been identified at this time. 

3. 6. 4 System Exceptions 

None have been identified at this time. 
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3.7 Other Model (Vehicle area of Renter's Vehicle sub-screen) 

3.7.1 Behavior 

This is a text field in which the user may enter a Model that was not available in the drop- 
down. If a value is entered, the Model (3.6) drop-down field should be cleared out if it 
has a value different from "Other Model". This field appears on all versions (Figure 1, 
Figure 2, Figure 3) of the application. 

3.7.2 Validation 

No validation is necessary. 

3. 7. 3 Business Exceptions 

None have been identified at this time. 

3. 7. 4 System Exceptions 

None have been identified at this time. 

3.8 Color (Vehicle area of Renter's Vehicle sub-screen) 

3.8.1 Behavior 

This is a drop-down field containing a list of available colors. If a Color different from 
"Other Color" is selected from the list, the Other Color (3.9) field should be cleared out. 
This field appears on all versions (Figure 1, Figure 2, Figure 3) of the application. 

3.8.2 Validation 

No validation is necessary. 

3. 8. 3 Business Exceptions 

None have been identified at this time. 

3.8.4 System Exceptions 

None have been identified at this time. 

3.9 Other Color (Vehicle area of Renter's Vehicle sub-screen) 

3.9.1 Behavior 

This is a text field in which the user may enter a Color that was not available in the drop- 
down. If a value is entered, the Color (3.8) drop-down field should be cleared out if it has 
a value different from "Other Color". This field appears on all versions (Figure 1, Figure 
2, Figure 3) of the application. 

3.9.2 Validation 

No validation is necessary. 

3. 9. 3 Business Exceptions 

None have been identified at this time. 

3. 9. 4 System Exceptions 

None have been identified at this time. 
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3.10 Is Car Drivable? (Loss Information area of Renter's Vehicle sub-screen) 

3.10.1 Behavior 

This is a drop down field containing the following domain values: 

• (Blank) - Default 

• Yes 

• No 

This field appears on all versions (Figure 1, Figure 2, Figure 3) of the application. 

3.10.2 Validation 

No validation is necessary. 

3.10.3 Business Exceptions 

None have been identified at this time. 

3.10.4 System Exceptions 

None have been identified at this time. 

3.1 1 Type of Loss? (Loss Information area of Renter's Vehicle sub-screen) 

3.11.1 Behavior 

This is a drop down field containing the following domain values: 

• (Blank) - Default 

• Damage 

• Theft 

This field appears on all versions (Figure 1, Figure 2, Figure 3) of the application. 

3.11.2 Validation 

No validation is necessary. 

3. 11. 3 Business Exceptions 

None have been identified at this time. 

3.11.4 System Exceptions 

None have been identified at this time. 

3.12 Total Loss? (Loss Information area of Renter's Vehicle sub-screen) 

3.12.1 Behavior 

This is a drop down field containing the following domain values: 

• (Blank) - Default 

• Yes 

• No 

This field appears on all versions (Figure 1, Figure 2, Figure 3) of the application. 

3.12.2 Validation 

No validation is necessary. 

3. 12. 3 Business Exceptions 

None have been identified at this time. 
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3.12.4 System Exceptions 

None have been identified at this time. 

3.13 Date of Loss (Loss Information area of Renter's Vehicle sub-screen) 

3.13.1 Behavior 

This is a text field in which the user may enter a date value. This field appeal's on all 
versions (Figure 1, Figure 2, Figure 3) of the application. 

3.13.2 Validation 

Entered data should be in a MM/DD/YYYY format. 

3.13.3 Business Exceptions 

None have been identified at this time. 

3.13.4 System Exceptions 

None have been identified at this time. 

3.14 Calendar button (Loss Information area of Renter's Vehicle sub-screen) 

3.14.1 Behavior 

This will bring up a calendar pop-up window allowing the user to select a specific date. 
The selected date will fill the Date of Loss (3.13) field. This button appears on all 
versions (Figure 1, Figure 2, Figure 3) of the application. 

3.14.2 Validation 

No validation is necessary. 

3.14.3 Business Exceptions 

None have been identified at this time. 

3. 14. 4 System Exceptions 

None have been identified at this time. 

3.15 Theft Waiver Days (Loss Information area of Renter's Vehicle sub-screen) 

3.15.1 Behavior 

This is a drop down field containing the following domain values: 

• (Blank) - Default 

• 1 Day 

• 2 Days 

• 3 Days 

This field only appears on the North American version (Figure 1) of the application and is hidden on the 
European versions (Figure 2, Figure 3). 

3.15.2 Validation 

No validation is necessary. 

3.15.3 Business Exceptions 

None have been identified at this time. 
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3.15.4 System Exceptions 

None have been identified at this time. 

3.16 Vehicle Notes {Renter's Vehicle sub-screen) 

3.16.1 Behavior 

This is a free form text field in which the user may enter data. The information entered 
here is only visible from this screen. This field appears on all versions (Figure 1, Figure 
2, Figure 3) of the application. 

3.16.2 Validation 

No validation is necessary. 

3.16.3 Business Exceptions 

None have been identified at this time. 

3.16.4 System Exceptions 

None have been identified at this time. 

3.1 7 Account Name (Shop sub-screen) 

3.17.1 Behavior 

This field's value is entered when: 

• User enters the Account name. 

• User clicks the "down arrow" button (3.18) to the immediate right and selects an 
Account from the Branch Short list. 

• User enters a valid number in the Account Number (3.19) field. That number's 
Account name value will then populate this field. 

• User clicks the "Search" button (3.20) and selects an Account from the Account 
Information list. 

• User clicks the "Not on File" button (3.21) and enters the appropriate new 
Account information. 

If an Account name is entered, the Account Number (3.19), Contact Name (3.22) and Phone Number (3.25) 
fields will then be populated. If the Account name is blanked out and the user tabs off or leaves the field, 
Account Number (3. 19) and Contact (3.22) will also be blanked out. This field appears on all versions 
(Figure 1, Figure 2, Figure 3) of the application. 

3.17.2 Validation 

No validation is necessary. 

3.17.3 Business Exceptions 

None have been identified at this time. 

3.17.4 System Exceptions 

None have been identified at this time. 
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3.18 Down arrow button (Shop sub-screen) 


3.18.1 Behavior 

This will bring up the Branch Short list allowing the user to select a specific Account. If 
in Europe, the European Branch Short list will be brought up. If an Account is selected, 
the Account Name (3.17), Account Number (3.19), Contact Name (3.22) and Phone 
Number (3.25) fields will then be populated. This button appears on all versions (Figure 
1, Figure 2, Figure 3) of the application. 

3.18.2 Validation 

No validation is necessary. 

3.18.3 Business Exceptions 

None have been identified at this time. 

3.18.4 System Exceptions 

None have been identified at this time. 

3.19 Account Number (Shop sub-screen) 

3.19.1 Behavior 

This field's value is entered when: 

• User enters a valid name in the Account Name (3.17) field. That name's Account 
number value will then populate this field. 

• User clicks the "down arrow" button (3.18) to the immediate left and selects an 
Account from the Branch Short list. 

• User enters the Account number. 

• User clicks the "Search" button (3.20) and selects an Account from the Account 
Information list. 

• User clicks the "Not on File" button (3.21) and enters the appropriate new 
Account information. 

If an Account number is entered, the Account Name (3.17), Contact Name (3.22) and Phone Number (3.25) 
fields will then be populated. If the Account number is blanked out and the user tabs off or leaves the field, 
Account Name (3.17) and Contact (3.22) will also be blanked out. This field appears on all versions (Figure 
1, Figure 2, Figure 3) of the application. 

Validation 

No validation is necessary. 
Business Exceptions 

None have been identified at this time. 
System Exceptions 

None have been identified at this time. 
Search button (Shop sub-screen) 

Behavior 

This will bring up the Account Search screen allowing the user to search for and then 
select a specific Account. If an Account is selected, the Account Name (3.17), Account 
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Number (3.19), Contact Name (3.22) and Phone Number (3.25) fields will then be 
populated. This button appears on all versions (Figure 1, Figure 2, Figure 3) of the 
application. 

3.20.2 Validation 

No validation is necessary. 

3.20.3 Business Exceptions 

None have been identified at this time. 

3.20.4 System Exceptions 

None have been identified at this time. 

3.21 Not on File button (Shop sub-screen) 

3.21.1 Behavior 

This will bring up the Add Account Not on File screen (Figure 4) allowing the user to 
enter information for a new Account. After all the necessary fields on that screen are 
entered, the Account Name (3.17), Account Number (3.19), Contact Name (3.22) and 
Phone Number (3.25) fields will then be populated with that screen's entered 
information. This button appears on all versions (Figure 1, Figure 2, Figure 3) of the 
application. 

3.21.2 Validation 

No validation is necessary. 

3.213 Business Exceptions 

None have been identified at this time. 

3.21.4 System Exceptions 

None have been identified at this time. 

3.22 Contact Name (Shop sub-screen) 

3.22.1 Behavior 

This field's value is entered when: 

• User enters a valid name in the Account Name (3.17) field. That name's Contact 
name value will then populate this field. 

• User clicks the "down arrow" button (3.18) to the immediate right of Account 
Name (3.17) and selects an Account from the Branch Short list. That Account's 
Contact name value will then populate this field's value. 

• User enters a valid number in the Account Number (3.19) field. That number's 
Contact name value will then populate this field. 

• User clicks the "Search" button (3.20) and selects an Account from the Account 
Information list. That Account's Contact name value will then populate this 
field's value. 

• User clicks the "Not on File" button (3.21) and enters the appropriate new Contact 
information after the new Account information. After all the necessary fields on 
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that screen are entered, that screen's entered information for Contact name will 
then populate this field's value. 

• User enters the Contact name. 

• User clicks the "down arrow" button (3.23) to the immediate right and selects a 
Contact from the Contact list. 

• User clicks the "Add New" button (3.24) and enters the appropriate new Contact 
information. 

This field appears on all versions (Figure 1, Figure 2, Figure 3) of the application. 

3.22.2 Validation 

No validation is necessary. 

3.22.3 Business Exceptions 

None have been identified at this time. 

3.22.4 System Exceptions 

None have been identified at this time. 

3.23 Down arrow button (Shop sub-screen) 

3.23.1 Behavior 

This will bring up the Contact list allowing the user to select a specific Contact. If a 
Contact is selected, the Contact Name (3.22) field will then be populated. This button 
appears on all versions (Figure 1, Figure 2, Figure 3) of the application. 

3.23.2 Vaiidation 

No validation is necessary. 

3.23.3 Business Exceptions 

None have been identified at this time. 

3.23.4 System Exceptions 

None have been identified at this time. 

3.24 New Contact button (Shop sub-screen) 

3.24.1 Behavior 

This will bring up the New Contact screen (Figure 5) allowing the user to enter 
information for a new Contact. 

After the necessary field(s) on that screen is/are entered, the Contact Name (3.22) field 
will then be populated with that screen's entered information. This button appears on all 
versions (Figure 1, Figure 2, Figure 3) of the application. 

3.24.2 Validation 

No validation is necessary. 

3.24.3 Business Exceptions 

None have been identified at this time. 

3.24.4 System Exceptions 

None have been identified at this time. 
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3.25 Phone Number (Shop sub-screen) 


3.25.7 Behavior 

This field's value is entered when: 

• User enters a valid name in the Account Name (3.17) field. That name's Phone 
number value will then populate this field. 

• User clicks the "down arrow" button (3.18) to the immediate right of Account 
Name (3.17) and selects an Account from the Branch Short list. That Account's 
Phone number value will then populate this field's value. 

• User enters a valid number in the Account Number (3.19) field. That number' s 
Phone number value will then populate this field. 

• User clicks the "Search" button (3.20) and selects an Account from the Account 
Information list. That Account's Phone number value will then populate this 
field's value. 

• User clicks the "Not on File" button (3.21) and enters the appropriate new 
Account information. That Account's Phone number value will then populate this 
field's value. 

• User enters the Phone number. 

This button appears on all versions (Figure 1, Figure 2, Figure 3) of the application. 

3.25.2 Validation 

No validation is necessary. 

3.25.3 Business Exceptions 

None have been identified at this time. 

3. 25. 4 System Exceptions 

None have been identified at this time. 

3.26 Button Line Area 

3.26.1 Behavior 

The Previous button will take the user to the Bill-to screen within the same transaction. 

The Next button will take the user to the Notes screen within the same transaction. 

The Complete button will initiate a save of the transaction. All validations will be 
performed, returning any errors to the user. If there are no errors, the transaction is 
saved, and the user is returned to the Open Ticket home page. 

4. Not on File (Figure 4) 

4.1 Name 

4.1.1 Behavior 

This is a text field in which the user may enter an Account name. 
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4. 1.2 Validation 

No validation is necessary. 

4.1.3 Business Exceptions 

None have been identified at this time. 

4. 1.4 System Exceptions 

None have been identified at this time. 

4.2 Address 

4.2.1 Behavior 

This is a free form text field in which the user may enter an Account's address, 

4.2.2 Validation 

No validation is necessary. 

4. 2. 3 Business Exceptions 

None have been identified at this time. 

4.2.4 System Exceptions 

None have been identified at this time. 

4.3 Zip 

4.3.1 Behavior 

This is a text field in which the user may enter an Account's zip code. 

4.3.2 Validation 

No validation is necessary. 

4. 3. 3 Business Exceptions 

None have been identified at this time. 

4.3.4 System Exceptions 

None have been identified at this time. 

4.4 Geographic Framework button (lightening bolt graphic) 

4.4.1 Behavior 

This will fill in the City (4.6) and State (4.7) fields if there is only 1 city for the zip code. 
If more than 1 city is in the entered zip code, the Multiple Cities Found page will be 
brought up, allowing the user to select a city. The City (4.6) and State (4.7) fields will 
then be filled with the user's selection. 

4.4.2 Validation 

No validation is necessary. 

4.4.3 Business Exceptions 

None have been identified at this time. 

4.4.4 System Exceptions 

None have been identified at this time. 
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4.5 Country 

4.5.1 Behavior 

This is a drop down field containing the list of countries. 

4.5.2 Validation 

No validation is necessary. 

4. 5. 3 Business Exceptions 

None have been identified at this time. 

4. 5. 4 System Exceptions 

None have been identified at this time. 

4.6 City 

4.6.1 Behavior 

This is a text field in which the user may enter an Account's city. This field may also be 
filled by actions performed by the Geographic Framework button (4.4). 

4.6.2 Validation 

No validation is necessary. 

4. 6. 3 Business Exceptions 

None have been identified at this time. 

4.6.4 System Exceptions 

None have been identified at this time. 

4.7 State 

4.7.1 Behavior 

This is a drop down field containing the list of states. This field may also be filled by 
actions performed by the Geographic Framework button (4.4). 

4.7.2 Validation 

No validation is necessary. 

4. 7. 3 Business Exceptions 

None have been identified at this time. 

4. 7.4 System Exceptions 

None have been identified at this time. 

4.8 Phone 

4.8.1 Behavior 

This is a text field in which the user may enter an Account's phone number. 

4.8.2 Validation 

Entered data should be 10 digits for the US to include area code or the appropriate format 
for other countries. 
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4. 8. 3 Business Exceptions 

None have been identified at this time. 

4. 8. 4 System Exceptions 

None have been identified at this time. 

4.9 Contact Last Name 

4.9.1 Behavior 

This is a text field in which the user may enter a Contact's last name for the new 
Account. 

4.9.2 Validation 

No validation is necessary. 

4. 9. 3 Business Exceptions 

None have been identified at this time. 

4. 9. 4 System Exceptions 

None have been identified at this time. 

4.10 Contact First Name 

4.10.1 Behavior 

This is a text field in which the user may enter a Contact's first name for the new 
Account. 

4.10.2 Validation 

No validation is necessary. 

4.10.3 Business Exceptions 

None have been identified at this time. 

4.10.4 System Exceptions 

None have been identified at this time. 

4.1 1 Button Line Area - Add Account Not on File 

4.11.1 OK button 

4.11.1.1 Behavior 

If data is not present in the required fields the feedback message explains that a value 
needs to be entered in the field(s) that is/are blank. Two options are presented, OK and 
Cancel. OK takes the user back to the Add Account Not on File screen for data entry; 
Cancel dismisses the Add Account Not on File screen. 
OK will be the default selection. 

4.11.1.2 Validation 

There must be data present in all fields except for Contact Last Name (4.9) and First 
Name (4.10) where only one needs to have data present. 
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4.1 1 .1 .3 Business Exceptions 

None have been identified at this time. 

4. 1 1 . 1 A System Exceptions 

None have been identified at this time. 

4.11.2 Cancel button 

4.11.2.1 Behavior 

This button will dismiss the Add Account Not on File screen without saving any data. 

4.11.2.2 Validation 

If data has been entered the following feedback message is displayed; "Are you sure you 
want to exit and lose the entered information?" Two options are presented, Yes and No. 
Yes will dismiss the screen and not save the data, No will take the user back to the Add 
Account Not on File screen. 
The default button selection is "No". 

4.1 1 .2.3 Business Exceptions 

None have been identified at this time. 

4.11.2.4 System Exceptions 

None have been identified at this time. 

5. New Contact (Figure 5) 

5.1 Last Name 

5.1.1 Behavior 

This is a text field in which the user may enter a Contact's last name for an already 
selected Account. 

5.1.2 Validation 

No validation is necessary. 

5. 1. 3 Business Exceptions 

None have been identified at this time. 

5. 1. 4 System Exceptions 

None have been identified at this time. 

5.2 First Name 

5.2.1 Behavior 

This is a text field in which the user may enter a Contact's first name for an already 
selected Account. 

5.2.2 Validation 

No validation is necessary. 

5. 2. 3 Business Exceptions 

None have been identified at this time. 
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5. 2. 4 System Exceptions 

None have been identified at this time. 

5.3 Button Line Area - Add Contact 

5.3.1 OK button 

5.3.1.1 Behavior 

If data is not present in the Last Name (5.1) and/or the First Name (5.2) field(s), the 
feedback message explains that a value needs to be entered for Last Name (5.1) and/or 
First Name (5.2). Two options are presented, OK and Cancel. OK takes the user back to 
the Add Contact screen for data entry, Cancel dismisses the Add Contact screen. 
OK will be the default selection. 

5.3.1.2 Validation 

There must be data present in the Last Name (5.1) and/or First Name (5.2) field(s). 

5.3.1.3 Business Exceptions 

None have been identified at this time. 

5.3.1.4 System Exceptions 

None have been identified at this time. 

5.3.2 Cancel button 
5.3.2 A Behavior 

This button will dismiss the Add Contact screen without saving any data. 

5.3.2.2 Validation 

If data has been entered the following feedback message is displayed; "Are you sure you 
want to exit and lose the entered information?" Two options are presented, Yes and No. 
Yes will dismiss the screen and not save the data, No will take the user back to the Add 
Contact screen. 

The default button selection is "No". 

5.3.2.3 Business Exceptions 

None have been identified at this time. 

5.3.2.4 System Exceptions 

None have been identified at this time. 

6. Rules 

6.1 Year, Make and Model domain values come from the database. 

6.2 A Contact must be selected for every Account that is selected as a Shop. 

6.3 The system should not search for or display any deactivated Accounts. 

6.4 User needs to have ability to cancel a search at any time during the search. 
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6.5 Notes should be generated when any of the following events occur: 


User adds a 
"Not on File" 
Shop 

Shop [Blank] was changed to 
"XXXX" 

Creat 
e/Edit 

Create (if data exists 
from the reservation) 
/Edit 

Vehicle/Sh 
op 

User adds a 
"Not on File" 
Shop Contact 

Not on File Contact "First Name Last 
Name" was added for Account 
"XXXXX" 

Creat 
e/Edit 

Create (if data exists 1 
from the reservation) 
/Edit 

Vehicle/Sh 
op 

User changes 
the Shop 
Account 

Shop "XXXX" was changed to 
"XXXX" 

Edit 

Create (if data exists 
from the reservation) 
/Edit 

Vehicle/Sh 
op 

User changes 
the Type of 
Loss 

Type of Loss "XXXX" was changed 
to "XXXX" 

Edit 

Create (if data exists 
from the reservation) 
/Edit 

Vehicle/Sh 
op 

| User changes 
the "Total 
Loss?" 

Total Loss "XXXX" was changed to 
"XXXX". 

Edit 

Create (if data exists 
from the reservation) 
/Edit 

Vehicle/Sh 
op 

User changes 
the Date of 
! Loss 

Date of Loss "XXXXXX" was 
changed to "XXXXXX" 

Edit 

Create (if data exists 
from the reservation) 
/Edit 

Vehicle/Sh 
op 

User changes 
! number of 

Theft Waiver 
1 Days 

Theft Waiver Days "X" was changed 
to "X" 

Edit 

Create (if data exists 
from the reservation) 
/Edit 

Vehicle/Sh 
op (North 
America) 

User changes 
the 

Registration 
Number 

Registration Number "XXXX 77 was 
changed to "XXXX" 

Edit 

Edit 

Vehicle/Sh 
op (Ireland, 

UK, 
Germany) 

User changes 
| the Class 

Class "XX" was changed to "XX" 

Edit 

Edit 

Vehicle/Sh 
op 

(Germany) 

User changes 
the Renter's 
j Vehicle's Year 

The Renter's Vehicle Year "XXXX" 
was changed to Year "XXXX" 

Edit 

Edit 

Vehicle/Sh 
op 

User changes 
the Renter's 
Vehicle's 
Make 

The Renter's Vehicle Make "XXXX" 
was changed to Make "XXXX" 

Edit 

Edit 

Vehicle/Sh 
op 

User changes 
the Renter's 
! Vehicle's 
Model 

The Renter's Vehicle Model 
"XXXX" was changed to Model 
"XXXX" 

Edit 

Edit 

Vehicle/Sh 
op 

User changes 
the Renter's 

The Renter's Vehicle Other Make 
"XXXX" was changed to "XXXX" 

Edit 

Edit 

Vehicle/Sh 
op 
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Vehicle Other 
Make text 





User changes 
the Renter's 
Vehicle Other 
Model text 

The Renter's Vehicle Other Model 
"XXXX" was changed to "XXXX" 

Edit 

Edit 

Vehicle/Sh 
op 


7. Security 

A user is authorized through a login process to create or edit a reservation or ticket. 
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Screen Action Specification 

1. Introduction 

This document will describe the behavioral characteristics associated with the Insurance Details screen. 

The system must be able to distinguish, presumably by the terminal ID, the proper screen language 
presentation as well as any field formatting applicable to that particular locale. 

2. Screen Print 


I DRIVERS 


(James Atteberry 
[Additional Drivers: 2 


REFERRAL 


[Account Name 
Icoritact Name 


DATES/RATES 


08/27/2001; ECAR 
Daily Rate; ASD 


BILL-TO 


Account Name 
Contact Name 


VEHICLE/SHOP 


1997 Dodge Avenger 
Shop Account Name 


NOTES 


Notes Taken: 1 


Drivers Insurance Detail 

.... . •• . 

Atteberry » J^EIuufl Hm! 

J;;H ■ : ■ James'. : E2E9 HZ32 



Driver 


Other Address 


Insurance Detail 


Cash Qualification 


-Insurance Details 

Carrier 

Agent Phone 



! Insurance Company Contact 

Policy Number Expiration Date 

i 


(MM/DD/YYYY) 

1 ! Comprehensive Deductible 

1 

Collision Deductible Liability? 

: Assigned Risk? 

i i 

Lienhoider Policy? 


[Tkt - 234567 Cbk - 363221 


Figure 1 - Insurance Detail 
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15 
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Hi 



24 


26 

27 

28 

1 29 

30 

31 






Figure 2 - Date selection 
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3. Insurance Details 

3.1 Carrier 

3.1.1 Behavior 

This is an alphanumeric field . 


3.1.2 Validation 

No validation is necessary. See Rules regarding when the field is required. 

3. 1.3 Business Exceptions 

None have been identified at this time. 

3. 1.4 System Exceptions 

None have been identified at this time. 

3.2 Agent 

3.2.1 Behavior 

This is an alphanumeric field. 

3.2.2 Validation 

No validation is necessary. The field is optional. 

3.2.3 Business Exceptions 

None have been identified at this time. 

3.2.4 System Exceptions 

None have been identified at this time. 

3.3 Phone 

3.3.1 Behavior 

This is an alphanumeric field. It should comply with the standard phone number field formatting. 
(06/05/2001- To date, no European considerations have been noted (waiting on update to Use Case). 

3.3.2 Validation 

The field is optional 

It should be edited to comply with the locale's format (i.e. in the United States, the length is 10 digjtsjmd 
include delimiters after the 3 ru and 6 tn characters. If no delimiters are used, but 10 digits are entered, thjTis 
also valid. ) 

3. 3. 3 Business Exceptions 

None have been identified at this time. 

3. 3. 4 System Exceptions 

None have been identified at this time. 
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3.4 Insurance Company Contact 


3.4.1 Behavior 

This is an alphanumeric field. 

3.4.2 Validation 

No validation is necessary. See Rules regarding when the field is required. 

3.4.3 Business Exceptions 

None have been identified at this time. 

3.4.4 System Exceptions 

None have been identified at this time. 

3.5 Policy Number 

3.5.7 Behavior 

This is an alphanumeric field. 

3.5.2 Validation 

No validation is necessary. See Rules regarding when the field is required. 

3. 5. 3 Business Exceptions 

None have been identified at this time. 

3.5.4 System Exceptions 

None have been identified at this time. 

3.6 Expiration Date 

3.6.1 Behavior 

Only numeric values and delineating characters will be accepted into this area. 

Associated with this field is a calendar function that allows the user to select a date from a calendar screen 
instead of entering a value. Clicking o n the calend ar icon will display the screen: once a date is selected 
Worn the screen the Expiration Date field will be populated with the appropriatejate. 

See Rules regarding when the field is required. 

3.6.2 Validation 

The date should be the current date or a date in the future. 

3. 6. 3 Business Exceptions 

None have been identified at this time. 

3. 6. 4 System Exceptions 

None have been identified at this time. 
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3.7 Comprehensive Deductible 

3. 7. 1 Behavior 

This is a numeric field. 

3.7.2 Validation 

No validation is necessary. See Rules regarding when the field is required. 


3. 7. 3 Business Exceptions 

None have been identified at this time. 

3. 7. 4 System Exceptions 

None have been identified at this time. 

3.8 Collision Deductible 

3.8.1 Behavior 

This is a numeric field. 

3.8.2 Validation 

No validation is necessary. See Rules regarding when the field is required. 

3. 8. 3 Business Exceptions 

None have been identified at this time. 

3. 8. 4 System Exceptions 

None have been identified at this time. 

3.9 Liability? 

3.9.1 Behavior 

The response is either 'Yes' or 'No', but the response is optional. There is no default value. 

3.9.2 Validation 

No validation is necessary. See Rules regarding when the field is required. 

3. 9. 3 Business Exceptions 

None have been identified at this time. 

3. 9. 4 System Exceptions 

None have been identified at this time. 

3.10 Assigned Risk? 

3.10.1 Behavior 

The response is either 'Yes' or 'No\ but the response is optional There is no default value. 

3.10.2 Validation 

No validation is necessary. The field is optional. 
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3.10.3 Business Exceptions 

None have been identified at this time. 


3.1 0.4 System Exceptions 

None have been identified at this time. 

3.1 1 Lienholder Policy? 

3.11.1 Behavior 

The response i s either 'Y es' or 'No\ but the response is optional There is no defaultvalue. 

3.11.2 Validation 

No validation is necessary. The field is optional. 

3.11.3 Business Exceptions 

None have been identified at this time. 

3.11.4 System Exceptions 

None have been identified at this time. 

4. Button Line Area 

4.1 Back button 

4.17 Behavior 

The Back button will take the user to the main Driver screen for the currently selected driver. 

4.1.2 Validation 

No validation is necessary. 

4.1.3 Business Exceptions 

None have been identified at this time. 

4.14 System Exceptions 

None have been identified at this time. 

4.2 Complete button 

4.2.7 Behavior 

The Complete button will initiate a save of the transaction. All validations will be performed, returning any 
errors to the user. If there are no errors, the transaction is saved, and the user is returned to the Reservation 
home page. 

4.2.2 Validation 

No validation is necessary. 

4. 2. 3 Business Exceptions 

None have been identified at this time. 
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4.2.4 System Exceptions 

None have been identified at this time. 


5. Rules 

5.1 Required Fields 

These fields are only required if information is present in any one of the following fields: CarrierJPolicY 
Number, Expiration Date. Collision Deductible, Comprehensive Deductible, Liability, Insurance Company 
Contact. If the system determines that any of the listed fields are missing information, the system wijjH 
present the user with a feedback message listing the incomplete required fields and directing them to " 
complete them. 

5.2 Saving 

Because none of the information on the screen is required, the user can leave the screen at any time during 
the course of making or editing the reservation or while opening, editing or closing the open ticket Unless 
any of thgfields in SUPL 76 are present.. The save is completed when the user saves the reservation s 
ticket. 

5.3 Tabbing 

Tabbing between fields should be in the order that they are in this document. 

6. Security 

The user must have the appropriate security level to access this screen. 
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Business Use-Case Specification: Callback Summary 


1. Callback Summary 
1.1 Brief Description 

The purpose of this use case is to show what a user (a branch employee, call center ) 
does to view a branch or group's list of callbacks needing to be performed for a given 
day. The user can select to view callbacks by a selected callback method whereby 
certain callback types are associated. 

2. Flow of Events 

2.1 Basic Workflow 

2.1.1 Use Case Begins 

This use case begins when a user chooses to view callbacks needing to be performed 
for a given day. The system retrieves ail inoompiete callbacks for the default group and 
branch (the defauit is the group and branch where the user logged in). If the user 
chooses to view callbacks for another branch within the group, see alternate flow view 
different branch . If the user chooses to view callbacks for an entire group, see alternate 
flow view different group . If the system does not retrieve any callbacks, see alternate 
flow no callbacks retrieved . 

2.1.2 Callback Method and Type Information 

The user has the option to select a callback method and callback type associated with 
the selected method. The callback methods and callback types available to the user 
are highlighted in the table below: 


Callback Method 
Manual Callback 

Callback Types Associate with the Method 
There are three types of callbacks associated to a Manual Callback. The 
user is able to select which type of callback to perform. The three types are 
listed below: 

• Shop 

• Bill-To 

• Renter 

Automated, Fax, and 

Consolidated 

Callback 

• The two types of callbacks associated with the 
Automated, Fax, and Consolidated Callbacks are: 

• Shop 

• Bill-To 

Manual Shop 

• Upon entry to the Summary, Manual Shop callback 
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